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Preface 


The  AFIT/orc  database  contained  the  means  to  store  student  data  and 
the  ability  to  nanipulate  this  data  utilizing  the  TOTAL  Database  Manage¬ 
ment  System.  This  stuc^  was  undertaken  to  expand  the  database  to  include 
faculty  data  and  additional  data-elements  for  use  in  future  applications, 
and  to  provide  a  standard  means  of  database  input  and  output  utilizing 
the  Forms  Managenent  Systan  (a  software  form  presentation  utility) ,  v^ch 
would  shew  standard  forms  to  the  user  on  the  CRT  for  the  iiput  and  out¬ 
put  of  data  to  the  database,  and  to  enhaixre  the  database  capabilities. 

I  thank  ny  advisor.  Dr.  Gary  Lament,  for  providing  a  thesis  topic 
which  Wets  most  Interesting,  Instructional,  and  a  useful  tool.  I  also 
thank  him  and  the  menbers  of  ny  thesis  comnittee  for  their  directions  and 
help.  Additionally,  I  thank  Robert  Ewing  for  his  support  and  many  hours 
of  expert  assistance.  I  thank  try  classmates  for  their  nuch  appreciated 
assistance  and  the  Amy  for  providing  the  OEportunity  to  attend  this 
course  of  Instruction.  Finally,  I  actacwledge  ny  deep  gratitude  to  ny 
wife,  Kerri,  for  her  unfailing  support  and  encouragement  throughout  the 
term  of  this  in-CXMJS  short  tour. 
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Abstract 

This  study  undertook  a  ccnplete  revision  and  redesign  of  the  AFIT/ 
ENG  database  in  an  effort  to  expand  existing  capabilities  and  utili¬ 
ties.  The  Softwcure  Develc^xnent  Life  Cycle  approach  was  utilized 
throughout  this  project  in  order  to  provide  a  basis  for  sound  software 
engineering  principles  and  provide  for  a  sound  database  development 
base.  The  initial  carpilation  of  data  was  obtained  by  interviewing  a 
wide  range  of  individuals  to  determine  required  functions  eis  well  as 
requested  data  items.  The  results  were  combined  to  form  the  specific 
network  master  and  variable  data-sets  for  use  with  anticipated  applica¬ 
tion  programs  for  a  greater  database  utility. 

The  expanded  database  exhibits  the  means  to  nvanipulate  student  and 
faculty  data  as  well  as  provide  for  the  inclusion  of  advanced  data 
handling  routines  like  education  plan  and  graduate  credit  record  utili¬ 
ties.  To  insure  standard  data  input  and  output  as  well  as  provide  a 
more  user  friendly  environment,  a  menu  form  display  technique  was 
incorporated  within  the  expanded  database  driver.  The  resultant  pro¬ 
gram  Wets  designed  for  modulcurity  and  expansion  with  little  additional 
coding  required  to  connect  future  database  application  routines. 


Chapter  1 


I .  Introduction 


Background 

The  means  and  methods  for  storing  data  in  a  corputer  based  record 
keeping  systan  has  greatly  expanded  fron  the  initial  develcpnent  of  the 
ccnputer  (1:3) .  Scientists  and  acadanicians  have  developed  and  iitproved 
many  methods  to  the  point  that  one  must  have  knowledge  of  a  number  of 
database  management  systans  in  order  to  choose  effectively  among  them 
when  determining  which  his  organization  will  use.  The  four  major 
components  of  any  databeise  systan  are  contained  in  data,  hardware,  soft¬ 
ware  and  users  (1:4) . 

The  Air  University,  as  with  any  organization,  requires  that  certain 
data  be  passed  among  its  different  functional  units.  As  with  the  nature 
of  individuals,  it  is  sometimes  easier  and  more  time  efficient  to  look 
up  data  already  available,  than  to  seek  anew  the  ans;^r  each  time  it  is 
asked.  A  prototype  database  has  been  established  in  the  Department  of 
Electrical  Engineering  Digital  Engineering  Laboratory  in  an  effort  to 
provide  maximum  classroom  instruction  for  its  students  and  at  the  same 
'^sist  the  School  of  Engineering. 

in  his  1980  thesis  (2) ,  proposed  the  establishment  of  a 
Consolidated  AFIT  Database.  A  database  'test-bed',  under  the  direction 
of  Dr.  Getry  Lament,  Department  of  Electrical  Engineering,  AFIT,  was  ccaa- 
structed  in  the  Fall  of  1983  and  located  in  the  Electrical  Engineering 
Digital  Engineering  Laboratory  (now  the  Informational  Sciences 


The  resultant  s\±iject  categories  centered  primarily  around 


iirproving  the  existing  portion  of  the  AFIT/EUG  Database: 

a.  User  Interface 

1.  Revising  default  actions 

2 .  Irtproving  menus 

3 .  Iitproving  user-friendliness 

b .  Design/ implementation 

1.  Adding  additional  links 

2.  Expanding  the  context  of  the  data  contained  with 
the  databcise 

c.  Adding  application  programs  to  assist  class  and  student 

advisors  and  Administrative  efforts 

This  thesis  effort  was  initiated  utilizing  these  subject  responses 
but  were  not  limited  to  them. 

Data  Base  Concepts 

The  interview  results  vgere  analyzed  to  determine  how  data  should 
be  structured  and  related,  and  which  items  should  be  included  in  the 
database  utilizing  a  network  DBMS.  Such  an  aspect  of  database  system 
implementation  involves  translation  of  the  specification  for  the  data¬ 
base  architecture,  which  is  formulated  independently  of  any  DBMS,  into 
the  characteristics  required  by  database  definition  under  a  particular 
DBMS.  This  is  accotplished  using  a  collection  of  statements  in  the 
selected  and  implemented  DBMS  package  data  description  language. 

Operations  on  the  database  itself  cire  invoked  by  application  pro- 
graims.  These  application  programs  may  be  run  as  jobs  in  the  jobstream 
or  may  operate  on  transactions  received  fron  a  ccmmunications  interface. 


'corporate  memory' ,  those  interviewed  were  most  cooperative  and  encour¬ 
aging.  All  conpleted  interviews  were  later  transcribed  to  disk  to 
assist  in  ccnpilation  and  determine  requirements.  Responses  were,  for 
the  most  part,  confined  to  the  tcpic  at  hand,  yet  a  number  of  subject 
areas  readily  appeeued.  The  subject's  individual  responses  to  the  inter¬ 
view  became  extensive,  and  are  contained  in  Appendix  B. 


Subject  Tcpic  Responses 

Upon  closer  scrutiny  of  the  interview  results,  a  number  of  more 
specific  topics  vere  determined  to  accurately  cover  the  subject  areas  of 
interest.  Table  2  contains  a  list  of  major  topic  areas  uncovered  during 
the  interviews,  with  the  number  of  interviewees  who  requested  data  or 
application  programs  pertaining  to  the  listed  category.  These  categories 
were  provided  by  the  subjects  in  order  to  he Ip  themselves  keep  track  of 
their  responses  during  the  interview.  The  categories  listed  reflect  a 
reduction  as  some  data  spanned  more  than  one  category.  The  contents  of 
each  category  are  found  in  Appendix  B. 

Table  II 


Major  Subject  Areas 


CATEGORY 

NUMBER  OF  TIMES 
SELECTED 

Clciss  Advisor 

7 

Management  Tool 

6 

Data  Requirements 

8 

Scheduling 

3 

Student  Information 

8 

Security 

5 

User  Friendliness 

8 

Faculty  Information 

6 

prior  to  conducting  the  personal  interviews,  each  subject  received  a  cc^y 
of  the  data  questionnaire  to  familiarize  themselves  with  both  the  content 
and  purpose  of  the  interview,  ^^jpendix  A  contains  the  questionnaire. 

The  questionnaire  cutlined  the  purpose  of  the  interview,  introduced 
the  interviewer,  e:q5lained  the  use  of  the  interview  results,  and  encour¬ 
aged  subject  responses  spontaneity  in  order  not  to  limit  the  scope  of  the 
interview  and  encourage  the  subject  to  feel  free  to  discuss  any  areas  of 
the  present  or  preposed  database  configuraticn.  The  individi;ials  inter¬ 
viewed  ranged  froti  Department  Head,  Deputy  Deparimient  Head,  current  and 
future  Class  Advisors,  instructors  and  secretaries  who  utilize  the  AFIT/ 
ENG  Database.  Table  1  shews  the  range  of  subjects  interviewed. 

Table  1 

Interview  Mix  by  Category 


CATEXXXiy 

NUMBER 

Class  Advisor 

6 

Secretaries 

2 

Prof essors/ Ins true tors 

10 

Department  Administration 

2 

Students 

5 

The  questionnaire  is  self-explanatory  in  nature,  intended  to  act 
only  as  a  means  of  eliciting  cements  and  to  thinly  confine  the  topic 
matter.  To  insure  ccnplete  and  accxirate  results,  and  help  the  subject's 
to  feel  more  at  ease,  all  interviews,  with  one  exception,  were  cassette- 
t^jed  and  conducted  in  the  subject's  office.  Interviews  ranged  from  20- 
90  minutes  in  length.  Although  this  was  another  series  of  interviews  in 
conjunction  with  a  thesis  investigation  regarding  the  AFIT  database, 
perhaps  due  to  the  quick  personnel  turnover  and  subsequent  short 


irtplCTented  in  this  manner,  it  should  be  able  to  expand,  if  necessary, 
to  encotrpass  additional  Electrical  Engineering  Department  requirements 
and  other  departmental  areas  within  the  AFIT  environment. 


The  interviews  were  detained  from  present  and  most  likely  users 
of  the  Database  Management  Sysban  (DBMS) .  Because  of  current  design 
constrednts,  present  users  are  few  and  mostly  confined  to  administration 
and  clciss  and  student  advisors.  Most  likely  new  users  were  defined  first 
to  be  inccming  cleiss  advisors  with  academic  advisors  (most  faculty 
menbers)  to  follcw  second.  Although  no  final  inplementation  plan  was 
determined,  individual  student  use  of  the  databeise  (apart  from  entering 
initial  personal  data  and  individual  education  plan)  is  anticipated  as  a 
later  expansion  (Appendix  N) .  The  interview  data  results  were  useful  in 
assisting  the  selection  of  the  best  potential  data  items  for  inclusion  in 
the  database,  projected  as  far  into  the  future  as  can  be  accurately  and 
practically  planned  (7:68) . 

Interview  Methodology 

An  inportant  requirement  was  to  determine  exactly  vdiat  information 
was  needed  to  plan  the  database  development.  Previous  interviews 
acccrplished  by  Allred  (2:20)  and  Ricks  and  Colburn  (3;IIIA.i)  were 
conducted  to  determine  specific  data  items  for  inclusion  in  a  databeise. 
The  methodology  used  during  this  thesis  effort  was  similar. 

The  manner  in  vdiich  an  interview  is  conducted  can  affect  the  type  of 
data  collected  and  subsequently  made  regarding  the  inplementation  scheme. 
Therefore,  rather  than  cbtaining  oily  administrative  input  requests  or 
only  cisking  respondents  to  fill  out  an  interview  form,  a  more  coordinated 
and  free  flowing  personal  interview  was  decided  upon.  At  least  a  day 


This  was  acccnplished  by  reviewing  a  number  of  official  and  unofficial 
ccranunications : 

1.  By  studying  the  peist  requested  data  requirements; 

2.  By  reviewing  data  generated  within,  as  well  as  data  directed  into, 
the  Electrical  Engineering  Department; 

3.  By  dDtaining  copies  of  data  kept  by  both  the  Electrical  Engineering 
Department  and  those  individuals  who  work  within  it. 

To  shorten  this  process,  personal  interviews  of  individuals  v^o  use 
and  will  most  likely  be  using  tlie  database  were  conducted.  The  results 
were  captured  and  collated  to  relate  to  functional  activities.  This 
information  provided  a  means  of  identifying  data  item  requirements  as 
well  as  user  requests  for  data  included  in  the  database  (7:21) . 

Identifying  data  item  requirements  is  a  major  step  to  determine  the 
direction  of  subsequent  work  on  this  staged  develcpnent  database  thesis. 
The  previous  thesis  efforts  directed  at  determining  the  conposition  of 
such  a  database  must  be  screened  and  results  weighed  to  insure  the  chosen 
direction  for  the  database  is  Ccuefully  considered.  What  is  not  desired 
is  a  databcise  placed  in  the  hands  of  individual  designers  and  prograimers 
vdio  implement  applications  on  a  function-by-function  basis  using  the 
pac)cage  sinply  as  an  access  method.  The  result  is  an  inevitable  replica¬ 
tion  of  the  old  file-oriented  systems,  only  with  more  keys  than  before 
and  with  more  conputing  resources  consumed  (7:1).  Centralized  control 
demands  a  centralized  description  of  both  the  problem  environment  and  the 
supporting  data.  It  also  requires  centralized  control  over  the  design, 
implementatican  and  maintenance  of  the  cuxhitectural  structures  that  make 
the  database  system  useful  for  the  user  conmunity  (7:1) .  With  the  system 
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Previous  work  was  done  by  Allred  (2)  and  Ricks  and  Colburn  (3)  to 
propose  and  define  an  AFIT  database.  These  studies  envisioned  the  v<^ole 
of  the  Air  University  system  tied  into  one  database  encatpassing  each 
AFIT  school,  administrative  requirements,  cis  well  as  related  services 
(bookstore,  etc.) .  This  chapter  covers  the  techniques  used  to  obtain  the 
data  for  the  analysis  used  in  the  Software  Development  Life  Cycle. 

A  database  'test-bed',  under  the  direction  of  Dr.  Gary  Lament, 
Department  of  Electrical  Engineering,  AFIT,  was  constructed  in  the  Fall 
of  1983  and  located  in  the  School  of  Engineering  Digital  Engineering  Lab 
(now  the  IS  Laboratory) .  This  was  accorplished  to  acknowledge  the  need 
for  an  AFIT  database.  Initially,  the  database  was  restricted  to  contain 
only  data  relating  students  and  their  selected  courses. 

This  thesis  effort  is  to  expand  the  initial  design  and  inplement 
additional  features  to  allcw  it  to  be  more  responsive  and  useful  for  day- 
to-day  activities  within  the  AFIT  Electrical  Engineering  Department. 

Sene  remaining  requirements  which  exist  are  to  determine  what  further 
system  design  is  needed,  vhat  priorities  should  be  placed  on  the  addi¬ 
tional  design  items,  and  how  to  best  merge  these  additional  requirements 
with  the  already  operational  database. 

Organizational  Requirements 

With  the  user's  need  already  established,  the  initial  step  was  to 
define  the  AFIT/ENG  Department  of  Electrical  Engineering  organizational 
requirements  to  determine  vhat  data  should  be  kept  within  the  database. 
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development  auid  iirplenentation  of  the  project  is  neither  expected  nor 
desired.  The  uniqueness  of  the  selected  network  Database  Managanent 
System  is  explained  on  a  need-to-know  basis  in  order  to  adequately 
eissist  the  reader. 

Material  and  Equipment 

Iirplementation  and  testing  utilized  the  existing  TOTAL  Database 
Management  System,  VAX  11/780  corrputer  with  the  VMS  curating  system, 
and  application  programs.  An  additional  mini  database  was  established 
with  copies  of  existing  application  programs  to  acccrplish  testing  and 
debugging.  In  order  to  further  isolate  this  project  frcm  the  present 
databcise,  sufficient  disk  manory  was  an  hand  to  insure  a  Icirge  enough 
area  to  hold  and  manipulate  the  revised  database  separately  frcm  the 
present  AFITDB. 


the  results,  and  to  tate  advantage  of  representing  ncrvement  and  trans¬ 
formation  without  regard  to  the  passage  of  time  during  this  view. 


Structure  Charts  (Appendix  M)  provide  a  visible  and  convenient 
method  for  portraying  the  interrelatiaiships  betveen  the  individual  soft¬ 
ware  modules.  Hierarchical  and  scope  of  ccxitrol  relationships  can  be 
easily  seen,  and  parameter  passing,  in  the  form  of  data  and  control  flags, 
can  be  effectively  identified  between  modules. 

Data  Flew  Diagrams  (AK>endix  M)  are  a  graphic  depiction  of  the  sys¬ 
tem  specification  that  identifies  inputs,  desired  out^juts,  and  data 
transformaticais.  This  usually  leads  to  the  definition  and  depiction  of 
modules  and  their  relationship  to  aie  another  and  to  various  system 
elements,  in  a  form  called  a  structure  chart. 

Further  Development  Aids  and  Assumptions 

To  insure  non-interference  with  the  current  in-use  database,  a  mini 
databese  was  ccnstructued  for  testing  purposes  with  the  same  logical 
characteristics  (file  names,  database  descriptor  names,  elements)  as  the 
live  database,  but  containing  only  a  subset  of  its  data  (i.e.,  5%  -  10%) 
(4:D-21) .  After  validating  that  an  c^lication  program  utilizing  the 
present  database  was  valid,  the  data  was  transfered  into  the  e:q)anded 
database  to  insure  corpatibility.  i^lication  programs  were  designed, 
written,  debugged  and  run  through  the  mini  database  first,  prior  to 
utilizing  the  coiplete  database.  After  this  the  ccnpleted  applicatiai 
programs  will  be  included  in  the  expanded  database. 

It  is  assumed  that  the  reader  has  a  good  technical  background  and  is 
scitevtot  familiar  with  database  concepts.  It  is  further  assumed  that 
continuous  and  exhaustive  explanaticsis  for  each  path  chosen  during  the 


message  and  may  return  scxre  fixed  test  value.  The  stub  is  eventually 
replaced  by  the  full  module  vrfiich  would  then  include  calls  to  other  stubs, 
In  this  manner,  an  entire  system  can  be  gradually  developed  and  tested 
(4:212) . 

A  major  development  in  facilitating  the  prograitming  task  is  known  as 
'structured  prograiming' .  This  premise  is  to  use  a  small  set  of  siitple 
control  and  data  structures.  A  program  then  is  built  by  nesting  these 
statanents  inside  each  other.  This  method  restricts  the  number  of  ccnnec- 
tions  between  program  parts  and  thereby  irrproves  the  comprehensibility 
and  reliability  of  the  program.  The  'if-then-else' ,  'while-do',  and 
'sequence'  statements  cire  one  ccnmonly  suggested  set  of  control  state¬ 
ments  for  this  type  of  prograitming  (4:211). 

Development  Tools  and  Documentation  Aids 

Two  Development  Tools  and  Documentation  aids  were  chosen  from  among 
the  many  currently  available.  Selectioi  criteria  included: 

1.  Clcurity  of  presentation 

2.  User  familiarity 

3.  Ease  of  modification 

4.  Availability  of  autcnated  storage  and  retrieval 

5 .  AFIT  requirements 

(5:15) 

Structure  Charts  were  chosen  over  Structured  Analysis  and  Design 
Technique  (SADT)  diagrams  because  they  were  rated  higher  in  'module 
coimiunication' ,  'training  need' ,  and  'proliferation'  (5:68).  Likewise, 
Data  Flow  Diagrams  were  chosen  as  an  antithesis  to  the  top-dcwn  approach 
in  order  to  reduce  the  effect  of  the  designer's  experience  and  biases  on 
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The  testing  stage  may  require  up  to  half  the  total  development  effort. 
Testing  is  divided  into  three  distinct  (^rations: 

1.  Module  Testing  -  tests  each  module  against  the  test  data  supplied  by 
the  prograitmer 

2.  Integration  Testing  -  tests  groups  of  carponents  together 

3.  Systems  Testing  -  tests  the  conpleted  systm  by  an  outside  group 

(4:200) 

Additional  types  of  testing  enconpasses  boundary  value  testing,  path 
testing,  equivalence  partitioning,  static  testing,  etc.  However,  the 
above  three  listed  operations  adequately  cover  the  useful  range  of  test¬ 
ing  used  within  this  project. 

Software  Engineering  Techniques 

The  Software  Encineering  Techniques  used  in  developing  the  software 
^  '  system  included  T<^>-down  E>esign,  Tcp-dcwn  Develcpment,  and  Structured 

Prograitming.  Top-down  Design  is  a  technique  in  which  a  programmer  first 
formulates  a  subroutine  as  a  single  statement,  which  is  then  expanded 
into  one  or  two  of  the  basic  control  structures  (SADT,  Data  Dictionary, 
Data  Flow  Diagram,  etc.) .  At  each  level,  the  function  is  expanded  in 
increasingly  greater  detail  until  the  resulting  description  becomes  the 
actual  source  language  program.  Using  this  ^proach,  also  called  'step- 
wise  refinement' ,  the  program  is  hiereuxjhically  structured  and  is  des¬ 
cribed  by  successive  refinements  (4:211). 

Top-down  develcpraent  is  another  technique  for  inplanenting  hierar¬ 
chically  structured  programs.  Here,  the  top)- level  routines  are  written 
first,  and  the  lower  level  routines,  called  stubs,  cue  written  to  inter¬ 
face  with  these.  The  stubs  return  ccxitrol  aifter  printing  a  simple 
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1 .  Requirements  Analysis 

2.  Specification 

3 .  Design 

4.  Coding 

5.  Testing 

6.  Operation  and  Maintenance 

(4:198) 

The  focus  of  the  Requiranents  Anal;^is  rests  on  the  interface 
between  the  conputer,  used  as  a  tool  to  solve  sene  prdDlem,  and  the 
people  vAio  need  bo  use  it.  A  Requir^ents  Analysis  can  aid  in  understand¬ 
ing  both  the  prdalem  and  the  tradeoffs  among  conflicting  constrednts, 
thereby  contributing  to  the  best  solution  (4:199) . 

While  Requirements  Analysis  seeks  to  determine  whether  to  use  a 
cenpater#  Specification  seeks  to  define  precisely  what  the  ccnpiter  is 
to  do,  but  not  how  to  do  it.  Issues  that  are  examined  at  this  stage 
include  input  and  output  record  formats,  database  layouts,  algorithm 
selections,  etc.  (4:199). 

In  the  Design  stage,  the  algorithms  called  for  in  the  Specifica¬ 
tions  are  develc^)ed,  and  the  overall  structure  of  the  cenputer  system 
takes  shape.  The  systen  is  divided  into  small  parts  (modules,  with  con¬ 
straints  as  to  function,  size,  and  speed  (4:200). 

Coding  is  the  stage  which  includes  the  use  of  high-level  languages 
and  structured  progranitiing  in  order  to  produce  the  mechanism  to  solve  the 
tcisk  at  hand.  Since  it  ajpears  that  most  errors  found  in  a  project  occur 
in  the  design  stage,  the  coding  stage  apparently  has  been  mastered 
better  than  any  other  (4:200) . 


The  project  began  with  preliminary  literature  research  on  those 
theses  which  led  to  the  present  AFIT/ENG  Database.  Personal  inter¬ 


views  of  current  and  possible  xisers  of  this  database  were  ccxiducted  to 
gather  information  with  viiich  to  support  the  expanded  database. 

Because  of  the  time  (four  yeaurs)  frcm  the  initial  concept  of  Allred's 
AFIT  Database,  and  the  partial  inplCTtentation  of  the  current  database, 
determining  updated  information  as  to  user  likes,  dislikes  and  require¬ 
ments  was  necessary.  Not  surveying  this  information  may  accept  blind 
implementation  of  specifics  proposed  for  different  requirements. 
Therefore,  after  validating  the  database  design  requiremnts  and  struc¬ 
turing  the  design,  the  proposed  aj^lication  programs  were  began. 

The  contents  of  the  current  AFIT/ENG  database  and  application  pro¬ 
grams  were  determined  and  cataloged  in  a  configuration  ccxitrol  docu¬ 
ment  to  provide  a  departure  point  from  which  to  build  the  remainder  of 
the  structure.  The  Software  Development  Life  Cycle  was  followed  as  a 
guide  to  develop,  operate  and  maintain  the  system.  The  Software 
Eiigineering  techniques  used  in  this  effort  can  be  classified  as  'tcp- 
down'  and  'structured'.  Both  of  these  techniques  have  proven  useful 
(6)  during  the  Softwcure  Development  Life  Cycle  of  a  project. 

Software  Development  Life  Cycle 

To  help  ccxitrol  the  develc^xtent  of  a  project,  six  separate  stages 
have  been  identified  through  v*iich  software  projects  must  pass.  These 
six  stages  make  up  the  Softwcure  Development  Life  Cycle; 
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existing  student  data,  incorporating  a  unique  form  display  technique, 
and  including  provisicxis  in  the  schema  and  database  for  pressed  applica¬ 
tion  prxjgrams. 


Scope 

The  main  effort  of  this  project  is  to  ccnplete  develcpment  and  iirple- 
ment  the  modifications  of  the  AFIT/ENG  database  with  specific  use  for  the 
Department  of  Electrical  Engineering,  Unlike  previous  theses,  this 
effort  is  confined  to  acquiring  and  using  student,  instructor  and  course 
data  utilized  within  the  AFIT/ENG  administrative  arena.  Although 
recognizing  the  need  for  an  all-inclusive  AFIT  and  Air  University  data¬ 
base  (2) ,  such  a  total  effort  is  not  now  supportable.  Thus,  no  specific 
work  is  accenplished  toward  iirplementing  the  CADIS  design  (3)  for  the 
rest  of  the  Engineering  School,  Logistics  School,  AFIT  Administration, 
scheduling,  operations,  personnel,  or  Air  University.  This  effort  is 
believed  to  not  only  provide  additicxial  insight  and  feedback  into  the 
future  development  of  such  a  database,  but  also  provide  immediate  use  of 
specific  application  programs  not  not/  available. 

Current  Knowledge 

The  AFIT/ENG  Database  currently  encompasses  most  needed  student  data. 
Application  programs  exist  vrtiich  produce  individual  course  enrollments, 
reduced  individual  student  Education  Plans  and  class  and  course  rosters 
(see  DBTA,  Informational  Sciences  Laboratory) .  At  this  stage  the  data¬ 
base  is  'student'  and  'course'  oriented. 
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Laboratory) .  Eitphasizing  the  aspects  of  data  security,  academic  envirai 
ment,  and  economic  reality,  this  database  has  been  installed  on  VAX/VMS 
11/780  vMch  has  a  limited  number  of  users  and  terminals.  The  database 
itself  is  limited  in  scope  and  inccttpiete  in  structure.  Dr.  Lamont's 
overall  objective  is  to  establish  a  working  database  useful  within  the 
Department  of  Electrical  Engineering,  AFIT. 

As  happens  within  organizations,  each  Department  stores  information 
dealing  with  assigned  students  and  faculty  vSiich  is  duplicated  not  oily 
within  itself  but  also  the  administrative  areas.  The  proposal  of  the 
Consolidated  AFIT  Databcise  wcis  an  attenpt  to  reduce  this  data  redundancy 
yet  provide  accurate  data  quickly  when  required.  The  inclusion  of  each 
student's  course  listing  by  quarter  was  introduced  to  alleviate  the 
duplication  of  requiring  every  student  to  register  each  quarter  thus 
reducing  scheduling  delays  as  well  as  confusion  betvreen  departments. 

This  Consolidated  Database  also  acts  to  reduce  redundant  application 
prograitming  to  increase  overall  efficiency  and  productivity. 

This  proposal  was  followed  by  another  database  thesis  proposal  (3) , 
classroom  projects  in  EE  646  (Ccnputer  Database  Systems) ,  and  DBTA 
efforts.  The  opportunity  for  students  to  work  within  a  database  and 
design,  write,  and  use  schemas  and  application  programs  while  studying 
these  concepts  allows  maximum  use  of  these  available  resources. 

Statement  of  Problem 

The  purpose  of  this  thesis  investigation  is  to  complete  development 
and  implement  the  AFIT/ENG  Database  utilizing  the  TOTAL  Database  Manage¬ 
ment  System.  Preposed  implementation  encetpasses  required  faculty  data 
schema  entries,  additional  academic  related  schema  entries,  expanding 


Whatever  the  source  of  activity,  the  application  program  executes  a 
logically  constructed  sequence  of  call  statements  on  the  DBMS.  Each  of 
these  calls  makes  reference  to  the  database  under  the  particular  data¬ 
base  architecture  and  for  the  specific  DBMS.  A  number  of  basic  apsplica- 
tion  program  topics  (2:21)  were  determined  which  mostly  enconpass  the 
present  expansion  effort. 

Within  the  database  design  methodology  each  existing  record's 
attributes  was  conpared  with  those  determined  to  satisfy  the  preposed 
database  requirements  utilizing  third  normal  form  attribute  techniques. 
Third  normal  form  can  be  loosely  defined  as  a  relation  'R'  with  a  family 
of  functional  dep)endencies  that  have  no  transitive  dependencies  (8:236). 
This  is  useful  for  the  following  reasons: 

a.  Avoids  redundancy 

b.  Forces  close  scrutiny  of  attributes 

c.  Assists  in  data  indepiendence 

i^pjendix  C  contains  the  data  entities  and  information  determined  to 
be  needed  to  expaand  the  current  AFIT/ENG  Database.  This  evolved  frem  the 
data  obtained  from  the  subject's  responses  outlined  in  i^pendix  B,  the 
data  items  contained  in  the  original  AFITDB  (J^pendix  E) ,  and  the 
individual  record  attributes  list  (2:i^pendix  B) .  Each  area  cited  for 
revision,  inclusion,  or  inprovement  was  examined  to  obtain  those  items 
which  would  satisfy  the  expected  database  requirements.  Although  the 
original  attributes  were  determined  utilizing  a  relational  database 
design,  and  this  effort  is  designed  utilizing  the  TOTAL  network  DBMS, 
similarities  in  data  items  and  files  (relations)  result.  Normalizing 
relations  in  the  relational  approach  assist  in  selecting  those  data-set 


itans  for  incliasion  within  a  network  data-set,  since  the  items  relate  to 
their  atcmic  values  (1:64-78) .  Direct  cottparisons  cannot  in  all  cases  be 
made. 


Prioritizing  New  Database  Requirements 

A  more  subjective  determination  of  v^ch  interview  responses  should 
be  irrplemented  and  in  what  priority  was  made  by  prioritizing  the  final¬ 
ized  list  of  interview  responses  as  contained  in  Appendix  D.  This 
analysis  vas  a  DBMS  coordination  exercise  with  the  user  (7:39)  .  It  was 
obvious  that  some  items  did  not  belong  in  what  is  envisioned  as  a  school 
support  multi-user  Database  (such  as  keeping  track  of  the  paperwork 
required  to  acquire  additional  ccnputer  resources,  and  maintaining  mail¬ 
ing  lists) .  It  was  also  clear  that  all  items  mentioned  could  not  be 
accomplished  in  one  project.  Table  III  contains  the  expanded  subject 
response  area  investigated  for  further  work  within  this  project.  Upon 
closer  scrutiny,  it  was  decided  that  portions  of  items  4  and  15  were 
adequately  covered  in  other  records  (existing  or  planned)  and  were 
deemed  inappropriate  for  inclusions  within  this  database.  They  were 
eliminated  from  further  consideration. 


Table  III 


Expanded  Subject  Responses 


NO. 

PRICRITY 

EXPANDED  STUDENT  RESPCNSES 

1 

★ 

Revise  Default  Thesis  Course  Credit 

2 

ie 

Iitprove  Menus  in  Database 

3 

* 

Additional  Links 

4 

Internal  Course  Data 

5 

* 

Include  Anry  Short  Coiarse  Students  in 

Database  Calculations 

6 

ic 

Link  Instructors  to  Courses 

7 

•k 

Student  Education  Plan 

8 

•k 

Determine  Teaching  Loads 

9 

* 

Graduate  Record  Data 

10 

it 

Instructor  Statistics 

11 

kk 

Room-to-Course  Scheduling 

12 

k 

Security/ Integrity 

13 

kkk 

Course  Grading 

14 

kk 

Faculty  Professional  Duties 

15 

Tracking  the  Acquisition  of  Cctrputer 

Equipment 

The  remaining  itens  vrere  awarded  a  three  tiered  status: 

1.  First  priority  -  * 

2.  Second  priority  -  ** 

3.  Third  priority  -  *** 

Ten  items  obtained  top  priority  (1-3,  5-10,  12) ,  two  items  obtained 

second  priority  (11,  14) ,  and  one  item  obtained  third  priority  (13) . 

The  highest  priority  was  awarded  to  those  items  vdiich  expand  the 
existing  database,  coiplete  functions  usually  considered  lengthy  and 
repetitive  (prime  candidates  for  computer  support) ,  and  which  currently 
have  no  other  means  for  acccrplishment  other  than  by  hand.  This  was 
accomplished  by  creating  additional  links  to  existing  data  elements  with 
newly  created  data  elements  in  an  effort  to  more  efficiently  utilize  and 
easily  expand  the  current  database.  Included  in  this  expansion  are 


proposed  utilities  to  assist  the  Administration,  Faculty,  and  Students  to 
determine  mid-course  and  end-of -course  requirements. 


An  exanple  of  this  is  the  MDEG  master  data-set.  This  data-set 
contains  data  elements  ccnsisting  of  the  degree  name  and  its  correspond¬ 
ing  designated  departmental  number  with  links  to  individual  courses  and 
course  sequences.  Extrapolating  this  into  an  as  yet  to  be  written 
application  program  will  provide  a  utility  to  check  a  student's  degree  or 
separate  sequence  qualifications. 

Some  requested  utilities,  although  seemingly  useful,  \«re  not 
determined  to  be  best  suited  for  inclusions  at  this  time.  A  few  subjects 
requested  a  rocm-to-course  scheduling  utility  (item  11,  Table  III)  vdiich 
EI4A  presently  determines  manually.  However,  until  the  database  is  able 
to  include  most  enrolled  AFIT  students,  a  separate  utility  for  this  pur¬ 
pose  will  fail  to  be  adequate  (although  the  anticipated  data  requirements 
were  included  in  the  database  schema) .  Also,  seme  instructors  requested 
a  facility  for  determining  course  grading  data.  This  also  was  not 
awarded  a  high  priority  due  in  part  to  the  varying  grading  methodologies 
and  the  availability  of  a  grading  program  available  on  many  of  the  micro- 
conputers  within  the  Department. 

Constraint  Specif ications 

A  complete  database  restructuring  would  utilize  previous  data  to 
insure  that  selected  hardwcure  and  software  would  provide  the  sought  after 
results  of  a  well  defined  databeise  with  ample  recall  and  use  utilities. 
Inasmuch  as  the  VAX  and  TOTAL  DBMS  were  among  those  items  deemed  capable 
of  supporting  the  Department  database  requirements,  this  selection 


alternative  was  not  consi<tered.  The  selection  of  a  network  over  a  rela- 
ticxial  or  hierarchical  scheme  was  centered  auxjund  the  ease  of  setup  (net¬ 
work  schena  vs  relaticxial  third  normal  form  or  better  schema  require¬ 
ments)  /  use,  and  avciilability  of  DBMS. 

This  thesis  investigation  vas  undertaken  to  expand  the  cinnrent  data¬ 
base  utilizing  existing  resources.  Some  ccMistrcunt  specifications  and 
required  resources  used  to  acccrplish  this  project  encatpciss  the 
following: 

-  VAX  11/780  in  Electrical  Engineering  Digital  Engineering  Laboratory 

-  TOTAL  DBMS  installed  on  this  VM  dictates  the  method  in  which 
^plications  programs  must  be  written 

-  Utilize  established  host  language  -  PASCAL 

-  Use  the  VAX-hosted  Forms  Management  System  to  produce  and  call 
menus  and  input/output  data  (to  reduce  screen  clutter  vhen 
providing  help  to  users  during  input/output  operations  and  also 
to  reduce  amounts  of  required  code  within  application  programs) 

-  Access  to  the  current  AFIT/EIJG  Database 

-  Access  to  the  current  database  application  programs 

-  Establish  a  Mini-database  for  testing  and  debugging  applications 
programs 

-  Anple  memory  to  acconmodate  the  above  specifications  and  resources 
The  specification  of  abstract  data  types  by  the  PASCAL  high-order 

progranming  language  lends  versatility  for  database  programming  since  it 
allows  the  progranmer  to  define  distinct  data  types  and  structures.  Also, 
since  PASCAL  is  used  and  taught  within  AFIT,  PASCAL  was  selected  for  use 
in  writing  the  code  for  this  thesis  effort.  In  this  way,  database  users 


and  administrators  would  already  have  some  familiarity  with  the  database 
language  used  for  future  database  examinations  and/or  modifications. 

The  input  and  oul^nit  of  data  to  and  from  the  database  has  been 
routinely  handled  by  extensive  and  verbose  prompting  requiring  many 
lines  of  separate  code,  for  input  or  output  data.  As  an  alternative  to 
this,  incorporating  the  use  of  the  utility.  Form  Management  System  (see 
Chapter  4) ,  provided  an  eaisily  transportable  and  modular  form  capability 
vrtiich  is  cc^)able  of  more  eaisily  altering  each  form  or  field  within  a  form 
than  the  present  system  vAiich  utilizes  embedded  code  within  the  applica¬ 
tion  program.  Additionally,  close  contact  with  the  Database  Management 
Administrator  (DBMA)  and  Database  Technical  Advisor  (DBTA)  were  most  use¬ 
ful  to  maintain  maxinum  support  and  eliminate  student  confusion.  Main¬ 
taining  data  independence  and  security  of  the  database  were  also  prime 
concerns  for  these  insure  that  the  database  can  be  transferred  if 
necessary  and  data  contained  within  the  database  is  relatively  safe  frcm 
unscrupulous  means. 

The  life-cycle  approach  for  the  development  of  the  AFIT  databeise 
includes  more  specific  determinations  for  the  pressed  contents  of  the 
database.  Additional  application  programs  are  expected  to  result  follow¬ 
ing  such  reviews.  During  the  database  life  cycle,  extensive  performance 
appraisals  of  both  the  data  relationships  and  programs  within  the  databeise 
must  continue  to  be  ccnducted. 

Throughout  the  construction  life  of  this  staged  database.  Security/ 
Integrity  procedures  must  continue  to  also  be  developed  eind  investigated. 
As  the  type  and  number  of  users  increases,  software  and  procedural 
security  procedures  for  such  cispects  cis  v^nat  data  users  may  access  and  how 
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they  nay  utilize  it  will  becctne  more  inportant  (9:193-194) .  Unauthorized 
acquisition  and  modification  of  data  must  be  an  integral  consideration 
when  adding  additional  afplication  modules  and  programs  (10:42-43) . 

Suwnary 

This  chapter  explored  the  general  guidelines  surrounding  the  process 
of  e^qanding  and  iitproving  the  present  Electrical  Engineering  Etepartment 
network  database  management  system.  Utilizing  the  Software  Develcptent 
Life  Cycle,  the  user  need  was  determined,  and  system  and  softwcire  require¬ 
ments  were  briefly  explained,  mostly  through  perscrial  interviews  and  pre¬ 
viously  completed  thesis  work.  The  requirements  definition  was  structured 
in  the  form  of  the  eiqjanded  database  DBG  (Database  Generation  Module) 
which  clarified  the  requirements  in  order  to  determine  how  to  best  meet 
user  needs.  Adapting  those  needs  to  the  identified  constraints,  enabled 
a  skillful  use  of  available  tools  to  enhance  the  DBMS  user  operation. 
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Chapter  3 


III.  Database  Design 

Ibis  chapter  will  cover  the  general  cireas  in  the  design  of  a  data¬ 
base.  Ibis  stems  from  the  guideline  of  the  softvrare  development  cycle, 
requirements  definition  analysis,  and  the  more  specific  aspects  relating 
to  the  iirplementation  of  a  databeise.  Also,  the  ccffistruction  of  a  data¬ 
base  utilizing  a  three-tiered  approach  will  be  discussed  and  weighed  as 
to  a  system's  success  or  failure. 

Databcise  is  the  organized  collection  of  data  items,  real  or  assumed, 
stored  in  a  data  structure  and  used  to  generate  the  information  enployed 
by  management  in  making  decisions  (11:1; 12; 20) .  This  is  often  managed  by 
a  Data  Bcise  Management  System  (DBMS) ,  a  blend  of  hardware  and  software 
vrtiich  has  custody  of  the  database.  The  DBMS  requires  a  data  base  defini¬ 
tion  which  tells  it  about  the  data  items  and  data  stnacture  that  it 
administers.  Database  design  is  a  process  that  leads  eventually  to  such 
a  database  definition.  Database  design  produces  preliminary  output 
called  a  logical  design,  and  a  second  step  (database  engineering)  ccxiverts 
this  to  the  dateJaase  definition  that  the  DBMS  expects. 

The  data  (facts)  describe  the  enterprise  or  business  or  school.  The 
information  is  produced  in  order  to  interpret,  correlate,  measure  and 
express  the  state  of  the  enterprise.  If  an  enterprise  (school)  decides 
to  change  its  accounting  practice,  procedure,  reporting  period,  or  for¬ 
mat,  it  is  the  procedure,  timing,  or  format  of  information  that  changes, 
not  the  data  (12:p.20) . 
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IXiring  data  base  design  ('logical'  design)  the  designer  has 
little  to  go  CMi  but  assurances  that  there  are  data  base  ' requirements ' . 
The  designer  tasks  atre  to  isolate  the  real  requirements,  gain  a  view 
of  future  requirements  and  a  plan  for  databeise  evolution,  and  analyze  the 
database  problem  so  far  as  to  formulate  a  'logical'  solution.  This 
early  phase  of  design  is  a  time  vriient 

-  There  is  no  design. 

-  Requirements  are  di^licated,  contradictory  of  ill-formed. 

-  Fundamental  key  items  are  ambiguously  defined. 

-  Expectations  of  database  utility  cue  ccxisiderable. 

-  The  existing  system  is  incomprehensible. 

-  Fantastic  (or  no)  records  cure  available  on  hew  the  systan  works. 
Here,  although  a  database  existed,  the  limited  nature  and  urgency 

with  v*uch  it  was  initially  constructed  prenpted  the  task  to  proceed  in 
the  absence  of  an  organized  framework.  The  database  design  process  may 
be  conducted  by  proceeding  through  a  number  of  stages: 

-  Focus  on  the  logical  design  problan,  separating  out  physical 
implementation  problems  (discussed  later) . 

-  'Factor'  the  data  problem,  looking  for  atcmic  entities  and  atomic 
relationships  between  than. 

-  Sketch  data  structures  that  neet  the  data  problem;  if  necessairy, 
leave  seme  entities  and  some  relationships  undetermined  while  the 
structure  is  being  developed. 

-  Dcxnjment  all  the  data  elements  and  the  relationships  among  them; 
use  this  preoess  to  refine  the  factoring  and  structuring  done 
earlier. 
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-  On  or  ne2u:  corpletion  of  the  design,  review  the  relationships  from 
a  dynamic  (additions  and  deletions)  point  of  view;  pursue  this 
review  to  include  changes  that  propagate  through  the  data  structure. 
Cleeurly,  the  actions  taken  in  the  last  few  steps  will  often  reflect 
back  (and  cause  changes)  to  the  earlier  work.  Thus,  the  process  is 
viewed  cis  proceeding  by  successive  refinements  until  the  logical  design 
is  complete  (11:2) . 

Although  'steps'  and  'stages'  are  mentioied  in  this  project,  it  is 
emphasized  that  throughout  the  process,  revisicai  and  redefinition  are 
ongoing.  There  are  numerous  reeisons  for  this: 

1.  Seme  based  on  previously  defined  data. 

2.  Some  bcised  cn  newly  included  data. 

3.  Some  based  on  deleted  itans,  vsrtiich  therefore  caused  either  1  or 
2  (above)  or  redefinition  of  data  or  links  to  take  place. 

A  Three-Tiered  Database  Approach 

Databcise  design  is  the  process  of  specifying  the  'logical'  relation¬ 
ships  that  data  items  beeu:  to  one  another,  given  that  these  data  items 
are  to  be  maintained  in  a  databased  systan.  In  the  data  processing 
literature,  the  work  'logical'  is  generally  another  way  of  saying 
'abstract',  but  it  is  not  true  that  database  design  is  entirely  abstract. 
The  eventual  outcome  of  database  design  is  a  working  database,  which  is  a 
highly  practical  objective  (11:4) . 

A  three- tiered  approach  is  a  simple  way  of  looking  at  how  a  database 
is  constructed.  The  initial  work  is  that  of  the  logical  design.  Second 
is  that  of  the  DBMS  selection,  v\hile  peirt  three  is  the  database 


engineering. 


The  sijbject  matter  of  database  design  is  dcndnated  by  data.  The 
designer  is  ccncemed  with  that  portion  of  system  development  that  deals 
with  endless  details  about  data:  the  names  of  data,  the  dynamic  proper¬ 
ties  of  data,  the  sources  and  end  uses  of  data,  etc.  In  spite  of  these 
details,  the  database  designer  must  retain  a  perspective,  in  order  not 
to  emerge  from  the  databcise  design  process  with  a  dull,  corplicated  web 
of  dreary  detail.  The  assignment  is  to  find  useful  order  and  place  the 
details  into  an  organizing  framework.  The  result  is  a  structure  that 
depicts  what  the  database  will  be. 

Failure  to  proceed  in  this  (or  like)  manner  will  cause  confusion, 
wcisted  space  in  the  database  and  increase  the  cost  in  terms  of  error 
checking,  system  response  and  usefulness.  Using  a  relational  approach, 
an  alternate  method  for  databcise  design  could  be  to  start  with  an  entity 
and  draw  it  as  a  bubble  chart  depicting  dependencies  between  each 
attribute.  As  each  attribute  is  added  to  the  chart,  each  is  checked  for 
similarity  to  previous  data  items,  redundancy,  relationships  to  other 
data  items  and  normalization  (13;Chapter  15). 

Logical  Design  vs  Physical  Design 

The  minimum  statement  of  vdiat  the  database  must  contain  (logical 
design)  was  determined  using  the  following  properties; 

-  The  data  items  suppoirted  in  the  data  structures  of  the  database 
were  identified  and  chciracterized.  This  is  a  data  inventory, 
complete  with  definitions  of  data  item  usage. 


-  Certain  data  items  were  given  special  attention.  These  are  the 
items  that  have  a  central  role  in  the  indexing,  linking,  keying 
and  naming  processes  which  give  the  database  its  organization. 


-  Nijmerous  rules  were  specified.  These  are  the  rules  under  vdiich  the 
key  data  items  are  connected  together  in  the  framework. 

-  Optinally  a  few  inportant  assunptions  were  recorded.  These  concern 
the  data  management  capability  required,  the  hardware  apparatus 
required  and/or  the  historical  records  to  be  preserved. 

'Logical  database  design'  is  separated  with  equal  ease  from  the 
database  engineering  work  which  follows.  The  Logical  databeise  design 
produces  concept,  framework  and  related  documentation  on  which  the  data¬ 
base  will  be.  The  Engineering  stage  yields  the  database  definition  (hew 
it  will  be  irrplemented) .  Creative  elements  are  added  during  the 
Engineering  stage  like: 

-  Data  item  size;  details  of  the  form  in  which  individual  data  items 
are  stored. 

-  How  to  deal  with  variable  length  records. 

-  How  to  deal  with  variable  nimbers  of  data  items. 

-  Selecting  a  database  management  system. 

-  Selecting  space  management  options. 

-  Qtploying  security  techniques.  (11:7) 

In  general,  quantification  of  record  sizes,  file  sizes,  etc.,  is 

all  physical  design  implemeritation.  The  fact  that  each  person  is 
identified  by  a  name  and  a  Social  Security  Number  (SSN)  is  logical 
design  inplementation.  Alternatively,  access  could  be  determined  by  an 
individual's  name  or  class.  The  fact  that  access  must  then  be  sufplied 
by  Social  Security  Number,  or  name  or  clciss  number  is  also  logical,  and 
that  access  is  provided  by  hashing  the  SSN  (name  or  class  number) ,  or 
inverting  it,  or  chaining  them,  is  a  physical  (Engineering)  decision. 


The  logical  design  keys  each  person  in  a  databeise  by  the  selected  key. 
There  cire  also  other  portions  of  the  database  that  can  be  linked  to  each 


individual  utilizing  this  key  as  a  *  link' .  But  is  is  left  to  the  Data- 
bcise  Engineer  to  decide  hew  that  linkage  fretn  each  person  to  those  other 
pieces  of  data  will  be  iitplemented.  The  particular  technique  (or  DBMS) 
used  will  determine  the  different  methods  of  achieving  identical  results. 

Utilizing  a  technique  imoch  like  factoring,  each  item  of  data  pro¬ 
posed  for  inclusion  into  the  database  Wc:s  sinplified  and  clarified  into 
atonic  elenents.  These  elenents  were  then  grouped  according  to  associa¬ 
tions  provided  in  the  interviews  in  order  to  determine  data  sets  or 
groups  of  like  data.  Those  items  with  an  affinity  for  more  than  one 
group  were  looked  at  to  determine  if  a  separate  group  would  better  suit 
the  database  needs  or  whether  this  might  add  the  associated  problem  of 
unnecessary  duplication. 

Fran  a  dynamic  point  of  view,  Database  can  be  reflected  in  four 
types  of  conputations ; 

1.  Building  of  the  data  collection. 

2.  Updating  of  data  elements  in  the  data  collection. 

3.  Retrieval  of  data  from  the  data  collection. 

4.  Reduction  of  large  quantities  of  data  to  usable  form. 


(14:5) 

AFIT  Enqinering  Database  Development 

The  building  of  any  data  processing  system  is  a  ccrplex  and  timely 
process.  There  cire  many  variables  to  be  properly  managed.  If  not 
handled  properly,  the  results  could  lead  to  eventual  failure  of  the 
system.  Eventual  failure  can  be  defined  to  be  the  user's  needs  not  met. 
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This  cxrcurs  if  the  systan  does  not  or  cannot  provide  the  infomiation  the 
user  needs.  The  system  may  be  unacceptable  if  the  response  tine  is  poor. 
Another  design  failure  exarrple  is  when  a  new  user  requirement  (or  an  old, 
forgotten  user  requirement)  renders  the  system  obsolete.  Other  reasons 
v^y  a  system  could  be  considered  a  failure  are  if  the  user's  on-line 
availability  requirements  cannot  be  met  by  ^plication  operations  or 
because  of  failure  to  fulfill  the  system's  off-line  requirements. 

The  best  insurance  against  such  failures  is  to  begin  with  a  well- 
planned  ccnplete  system  design.  However,  managing  the  complex  variables 
involved  in  building  a  database  application  is  no  easy  task.  Good  data¬ 
base  and  application  design  techniques  gained  from  experience,  classes, 
books,  and  so  on,  must  be  merged  with  the  reality  of  specific  user 
requirements  (15:xi). 

Selecting  a  DBMS 

One  of  the  aforenentioned  three  major  tasks  in  the  construction  of 
a  database,  DBMS  selection,  was  not  dealt  witJi  in  this  thesis,  since  a 
network  DBMS  had  already  been  selected  and  installed  on  the  host  hard¬ 
ware.  The  type  of  conputer  system  was  also  not  a  part  of  this  project 
since  this  also  had  been  procured  and  is  used  to  support  other  research 
work  as  well  as  maintain  administrative  data  for  the  Electrical  Engineer¬ 
ing  Depcirtment  of  the  School  of  Engineering,  AFIT. 

Since  the  selection  of  a  DBMS  and  hardware  support  system  had  pre¬ 
viously  been  acccitplished,  these  aspects  of  constructing  a  database  were 
thus  unnecessary  toward  the  successful  catpletion  of  the  project.  This 
takes  some  of  the  physical  hardware  objectivity  out  of  the  task,  but  this 
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2500  variable-entry  files  and  vice  versa  (18:3-5) . 


Indexing  Capabilities 

TOTAL  relies  on  calculated  indexing  (i.e.,  randctnizing)  to 
retrieve  data.  Single-entry  records  are  located  based  upon  the  random¬ 
ized  value  of  the  master  key.  Vciriable-entry  files  may  be  read 
serially,  although  keys  are  usually  accessed  through  linkage  paths  for 
the  single-entry  file(s) .  TOTAL  allows  a  single-entry  file  to  be 
linked  to  any  variable-entry  file  in  the  database.  In  a  sense,  single¬ 
entry  files  serve  as  tabular  indexes  to  variable-entry  files;  queries 
generally  cannot  be  resolved  within  single-entry  files.  In  TOTAL,  a 
tabulation  represented  by  a  single-entry  file  may  represent  a  tabular 
indexing  to  a  niomber  of  variable-entry  files  in  the  database  system. 
Furthermore,  variable-entry  files  may  have  such  an  indexed  reference 
from  any  member  of  single-entry  files.  Users  can  reference  a  master 
file,  search  through  an  associated  detail  file,  locate  records  in  that 
file  on  certain  criteria  from  which  the  key  values  for  referencing 
another  master  file  can  be  achieved. 

Data  Access ,  Entry,  Update,  and  Deletion 

Data  sets  are  accessed  through  a  Data  Manipulation  Language  (DML) 
that  is  set  up  in  a  CALL  statement  via  a  host  language  like  COBOL, 
FORTRAN,  PASCAL  or  ASSEMBLER.  Single-entry  data  files  are  retrieved 
directly  through  a  randotiization  algorithm  of  its  key.  Variable-entry 
files  are  accessed  along  a  lintege  path  with  a  specific  master  record. 
Records  can  be  read  forward  or  in  reverse  (i.e.,  starting  from  either 


data  for  processing.  It  my  be  described  as  a  partially  inverted  system 
oirganized  into  a  network  of  file  structures.  The  inverted  list  is  dis¬ 
tributed  as  linkages,  chains,  or  pointers  within  the  data  records  them¬ 
selves.  The  records  are  all  fixed  length  and  are  categorized  by  the 
type  of  data  file  to  vrtiich  they  belong.  TOTAL  can  manage  virtually  an 
'unlimited'  number  of  files  in  an  ' integrated, nonredundant'  basis  and 
provides  for  cissociation  of  each  of  these  files  with  other  related  files 
to  form  an  integrated  database. 

File  Types 

There  cure  basically  two  types  of  data  files,  single-entry  files  and 
variable-entry  files.  Records  in  a  single-entry  file,  which  is  often 
viewed  as  a  master  file  in  the  traditional  file-oriented  system,  contain 
the  master  key  for  a  cohesive  information  set  that  is  distributed  through 
the  associated  variable-entry  files.  The  master  key  can  be  up  to  256 
bytes  long  cind  must  have  a  unique  value.  The  records  themselves  are 
positioned  randomly  according  to  a  user-transparent  randonization  of  the 
master  key  value. 

Variable-entry  (or  detail)  files,  on  the  other  hand,  are  organized 
serially  so  that  successive  records  are  physically  stored  in  the  first 
available  data  cirea  within  a  file's  allocated  space.  They  are  logically 
linked  to  other  similar  data  entries  in  the  variable-entry  file  as  well 
as  to  the  associated  single-entry  record  to  which  it  belongs. 

Database  Growth 

The  maximum  number  of  records  in  a  TOTAL  database  is  limited  by  the 
peripheral  storage  available.  Any  single-entry  file  may  be  linked  to 
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deleted.  The  tc^ level  relations  cannot  be  processed  serially  because 
of  the  use  of  direct  file  access;  only  unordered  sequential  access  is 
possible.  This  may  force  seme  relations  to  the  bottem  level  vhich 
otherwise  wcxild  fit  better  on  tcp. 

Since  no  new  relations  or  new  linkage  types  can  be  dynamically 
created,  an  aissociative  relation,  such  as  supplier_assembly,  has  to  be 
created  at  the  time  the  schema  is  defined  and  will  be  updated  as  its 
owners  change. 

TOTAL  Design  Principles 

Opportunities  to  enhance  the  basic  design  should  be  explored  by  the 
TOTAL  user.  The  limitations  of  TOTAL  must  also  be  recognized.  With 
this  knowledge  of  TOTAL,  the  designer  can  examine  the  system  needs  and 
identify  a  practical  database  design  which  utilizes  the  advantages  to 
the  fullest  and  bypasses  the  drav±)acks  (16:3-9) .  The  designer  must  be 
alert  to  the  nature  of  the  system  taking  care  not  to  make  use  of  an 
opportunity  just  because  it  exists  when  the  advantage  would  be  only 
'icing  on  the  cake'.  By  the  sane  token,  tte  designer  should  not  be  put 
off  by  the  limitations  of  the  DBMS  until  the  analysis  shews  that  the 
limitations  cure  an  obstacle  in  this  system.  The  appropriate  steps  can 
be  taken  to  resolve  the  issue.  In  other  words,  the  database  designer 
should  not  create  a  problem  where  none  exists. 

TOTAL  Characteristics 

The  TOTAL  database  management  system  provides  an  effective  means 
for  organizing  and  managing  diverse  data  so  that  application  analysts/ 
prograntners  can  efficiently  and  conveniently  maintain  and  retrieve  the 


TOTAL  Network  Structure 


The  ta^)- level  relations  are  irtplemented  as  direct  files,  and  the 
botton  level  relations  as  chains.  The  chains  are  like  rings  without  a 
final  link  back  to  the  top-level  record.  A  record  of  a  relation  at  the 
bottom  level  may  be  in  multiple  chains  in  order  to  form  associations  of 
entity  relations,  eis  shewn  by  the  siapply  record  in  Figure  IV-1  (14:435) . 

Multiple  chains  may  emanate  from  one  entity  tuple  and  can  refer  to 
different  record  subtypes  within  one  subsidiary  relation.  This  allows 
simulation  of  the  required  three- level  hierarchy  of  ertployee. children, 
education  by  a  two  level  hierarchy  eTployee.children_education  as  shown 
in  Figure  IV-2. 

Reference  relations  and  lexicons  are  best  placed  in  the  role  of 
entity  relations  at  the  top  level.  When  they  refer  in  turn  to  relations 
on  the  bottom  level  they  can  use  linkages.  Linkages  to  inp lament  addi¬ 
tional  levels  have  to  be  handled  by  the  application  programs,  using 
symbolic  references.  Output  attributes  vdiich  provide  arguments  for  re¬ 
entry  into  the  network  from  the  top  are  indicated  in  Figure  IV-1. 

All  linkages  maintained  by  TOTAL  are  defined  in  the  schema.  They  are 
created  and  modified  automatically  when  a  record  is  inserted.  The  link¬ 
ages  are  not  essential;  a  ccnplete  ruling  part  is  kept  in  all  bottom- 
level  records.  Since  the  chains  do  not  return  to  the  parent  or  owner 
records,  the  key  in  the  ruling  peurt  provides  a  symbolic  reference  argu¬ 
ment,  which  is  the  only  means  to  locate  the  parent  or  owner  of  a  bottom- 
level  record. 

Deletion  of  an  entity  record  is  not  permitted  as  long  as  chain 
manbers  cire  linked  to  it,  so  that  in  the  example  the  relevant  records  in 
children_education  have  to  be  deleted  before  the  employee  record  can  be 


pcurt  of  structure.  These  structured  references  are  refered  to  as 
links. 

Links  can  be  inplemented  reference  structures  (pointers,  symbolic, 
indirect)  since  they  defer  the  binding  and  hence  the  existence  of  a 
network  to  query  processing  time  (17:1151-1152) .  Direct  pointer  ref¬ 
erences  can  be  used  only  if  records  are  not  moved  within  the  database 
during  their  lifetime,  since  otherwise  the  pointers  lose  validity.  In¬ 
direct  pointers  can  be  changed  by  changing  the  pointer  index  vdien  records 
are  moved.  Indirect  pointers  are  therefore  the  cotmon  means  to  inp lament 
linkages . 

Pointer  or  indirect  references  may  describe  the  structure  redundantly 
because  of  the  continued  existence  of  symbolic  references.  If  such 
pointer  or  indirect  references  are  not  redundant,  however,  this  is  some¬ 
times  refered  to  as  essential  links. 

Loss  or  invalidation  of  a  link  ittplies  loss  of  information.  Main¬ 
tenance  files  using  essential  links  requires  carefully  worked  out  pro¬ 
cedures  to  avoid  validation  of  these  links.  In  many  network  systems, 
links  are  essential  although  an  application  designer  may  decide  to  main¬ 
tain  redundancy  of  links  keeping  symbolic  references  within  the  data 
records  (14:434). 

A  Simple  Network  Imp lemen ta t ion 

TOTAL  provides  two- level  network  hierairchy.  The  top  level  contains 
entity  relations,  and  the  bottom  level  contains  either  nest  or  associative 
relations.  Figure  IV-1  shows  the  placement  of  relations  in  such  a 


structure 


Inability  to  obtaiin  a  piece  of  information  from  items  already  contained 
within  the  database  (or  the  costly,  lengthy  search  for  an  item)  was  also 
considered  as  a  basis  for  inclusion. 

Also,  a  data  item  determined  from  the  personal  interview  process  did 
not  guarantee  a  place  within  the  database  if  the  item's  marginal 
utility  was  not  deemed  sufficiently  high.  The  AFIT  Database  was  not  es¬ 
tablished  to  duplicate  individual's  personnel  records,  although  items 
like  date  of  birth,  place  of  birth  and  name  of  spouse  were  among  those 
items  included.  For  the  same  rationale,  no  student  awards  history  data 
was  e3g3ected  to  be  kept  other  than  data  that  related  to  those  awards 
received  while  at  AFIT,  and  then  this  data  was  expected  to  be  used 
strictly  for  administrative  accountability  purposes. 

Since  a  databeise  has  numerous  requirements  to  meet,  the  selection  and 
ordering  of  these  atonic  data  elements  for  inclusion  within  the  database 
was  the  next  step  in  the  design  process.  The  entire  project  was 
developed  using  the  TOTAL  DBMS.  Therefore,  the  database  design  conformed 
to  the  basic  file  structures  and  characteristics  of  TOTAL. 

TOTAL  DBMS 

Initially,  the  primary  questions  that  come  to  mind  are;  'What  is 
it?',  and  'How  does  it  work?'.  A  stcurting  point  is  to  say  that  it  is  a 
network  database  system. 

A  network  is  created  viien  structures  more  cotplex  than  hierarchies 
cure  bound.  A  hierarchy  is  as  cotplex  a  structure  as  can  be  built  using 
ordering  conventions  for  the  segments.  Even  then  reference  pointers  are 
found  in  many  inplementations.  In  a  network  references  are  an  inherent 


3.  Failure  to  design  for  future  data  requiremsnts. 

4.  Failure  to  design  for  future  user  expansion. 

This  allowed  an  iirportant  opportunity  for  the  organization  to  obtain  a 
new  beginning.  An  additicnal  consideration  was  to  obtain  the  full  sip- 
port.  of  the  Data  Base  Administrator  (DBA) .  This  is  of  irtmense  value 
v^ien  attoipting  a  database  reconstructiai  or  update. 

This  technique  contributed  to  unccnstrained  thought  and  far  reaching 
visions  for  future  database  design  concepts.  The  logical  design  process, 
almost  be  definition,  is  charged  with  tadcing  a  long-range  view  of  the 
data  needs  of  the  enterprise  (10:33) .  Appendix  0  contains  a  short 
explanation  and  proposed  organization  for  the  AFIT  Database  Administrator. 

The  use  of  the  personal  interview  had  numerous  effects.  The  con¬ 
tacted  individual  felt  as  if  their  inputs  aided  in  the  design  process. 
Because  differing  levels  of  supervision  were  contacted  within  the  admin¬ 
istration,  a  multi-dimensioned  information  and  use  requirement  was 
insured.  Also,  no  third  party  or  intermediary  was  involved  to  taint  the 
contents  or  results  of  the  interview  (no  third  party  impressions  of  the 
intervievrers) . 

After  transcribing  and  refining  all  responses,  the  next  task  under¬ 
taken  was  to  determine  atonic  data  items  retained  in  the  database.  The 
atomic  data  items  vere  determined  (Appendix  C)  based  on  the  perceived 
user  need  for  items  of  data  (including  supervisory  requirements) .  The 
ultimate  use  of  these  selected  values  was  not  the  primary  selection 
criteria  for  their  inclusion  as  an  atonic  data  value.  Items  kept  were 
determined  by  their  value  as  a  required  piece  of  data,  not  just  that  they 
help  satisfy  a  request  for  a  utility  or  direct  application  program. 


Chapter  4 


IV.  AFIT/EMG  Database  Requirements  and  Specifications 

This  chapter  will  review  and  expleiin  in  more  detail  the  steps  under¬ 
taken  to  effect  the  expansion  of  the  APIT/ENG  database  and  will  follow 
the  transition  of  raw  interview  data  through  irtplemented  database  schema. 
The  capabilities  and  shortccmings  of  the  utilities  used,  TOTAL  DBMS  and 
the  Form  Management  System,  will  be  presented  and  explored.  The  steps 
utilized  in  interfacing  these  utilities  with  the  required  prograimung 
languages  will  be  shown  to  satisfy  the  Softwaure  Development  Life  Cycle 
stages  as  well. 

The  initial  step  taken  in  this  thesis  effort  is  to  determine  exactly 
vhat  information  is  required  to  accurately  reflect  the  database  design. 

^  #  A  description  of  the  database  requirements  is  necessary  to  design  an 

integrated  database  system.  This  means  collecting  the  information  used 
to  generate  the  processing  programs  that  deal  with  the  database.  As  an 
exanple,  if  an  operational  database  is  available,  using  a  conventional 
file  system,  we  can  begin  by  reviewing  the  usage  of  the  file  system  by 
the  programs  that  cerate  on  the  fragments  of  the  database  (14:369) . 

Personal  interviews  were  conducted  and  the  results  tabulated  (see 
Chapter  2) .  This  technique  eliminated  a  number  of  possible  pitfalls. 

1.  First  and  foremost,  not  realizing  the  perceived  need  of  the 
database. 

2.  Utilizing  an  old  database  design  without  realizing  what  changes 
may  require  data  updates. 
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certain  items  of  data  were  solicited  during  the  design  phase  of  the 
project. 

Summary 

This  chapter  covered  the  techniques  utilized  in  the  design  of  the 
AFIT  database  expansicai.  The  method (s)  used  ccnsists  of  looking  at 
three  levels  or  tiers: 

1 ,  Logical  design 

2,  DBMS  selection 

3 ,  Databcise  Engineering 

The  stages  of  system  development  and  system  priorities  were  also  pre¬ 
sented  for  consideration  in  the  selection  and  inplementation  in  the 
design  of  a  databcise. 


4.  System  develOFnent  time  -  hew  nuch  time  hcis  been  spent  on 
background  develcpnent 

5.  Systan  availability  -  when  data  may  be  accessed,  not 
necessarily  when  'system'  is  functioning 

6.  Systan  flexibility  -  inportant  since  futxire  change  or 
modification  of  any  systan  is  anticipated 

7.  Data  integrity/ security: 

-  Integrity:  Are  there  requirements  for  controls,  journaling 
or  audit  trails? 

-  Security:  Is  the  data  in  the  database  sensitive? 

Is  encryption  necessciry? 

8.  Reliability/availability  of  information: 

-  Reliability:  When  data  changes,  hextf  soon  does  user  need 
to  have  updated  information  available? 

-  Availability:  Does  the  user  have  changing  requirements  to 


have  data  presented  in  a  number  of  ways? 


(15:65) 


Although  all  the  above  items  are  ixrportant,  not  all  may  be  as 
inportant  at  a  given  time.  However,  all  these  points  were  utilized  as 
guidelines  as  much  as  possible  during  the  design  and  irrplementation  of 
the  database.  Since  the  project  undertook  the  building  of  a  database, 
it  necessarily  included  the  tasks  of  data  collection,  data  organization, 
and  data  storage.  Data  organization  and  data  storage  were  items  mostly 
dealt  with  during  the  project.  Data  collection,  because  it  is  routinely 
handled  by  the  administration,  was  not  directly  dealt  wiui  during  the 
course  of  the  project.  As  stated  earlier,  however,  their  needs  for 
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the  infonnation  model  to  a  physical  storage  model) ,  and  determining 
program  specifications.  The  database  structure  is  also  diagramed  to 
provide  a  better  picture,  not  only  of  the  basic  structure,  but  also  to 
better  project  relationships  among  the  data-sets  and  to  act  as  a 
reference  for  the  prograititung  effort  yet  to  be  addressed. 

The  final  two  stages,  prograitming  and  testing,  by  far  take  up  the 
remainder  of  the  effort.  Inherent  within  this  coding  effort  is  the 
necessity  to  code  for  device  media  control  language  and  the  data  defini¬ 
tion  language  (DDL) .  Having  a  structured  database  is  not  the  end,  how¬ 
ever.  There  still  exists  the  requirement  to  code  for  data  manipulation 
language  and  program  logic,  and  load  the  program  (16:98) .  The  user  only 
is  awcure  of  the  tasks  the  database  can  perform,  not  the  process  v^ich 
must  be  ccnpleted  prior  to  the  first  application  program  executing. 

With  regard  to  cost,  the  resources  of  time,  manpower,  etc.,  spent  on 
analysis  and  design  prior  to  progranining  are  inexpensive  in  the  long 
run.  For  purely  economical  reasons,  discovering  poor  design  practices 
is  best  done  as  early  in  the  development  cycle  as  possible  (16:15) . 

System  Priorities 

Priorities  must  be  established  for  the  development  and  operation  of 
the  database.  Each  priority  must  then  be  weighed  as  to  their  critica¬ 
lity  for  use  within  the  database.  The  following  items  are  among  those 
which  are  important  considerations: 

1 .  Response  Time 

2.  User  function  -  eeise  of  use 

3.  Volume  of  treinsactions 


does  nothing  to  change  the  effects  or  requirements  for  the  other  two 
parts.  Each  part  must  still  be  determined  and  subsequent  conclusions 
drawn. 

System  Development  Stages 

In  one  form  or  another,  most  systems  generally  proceed  in  the 
development  as  shown  in  Figure  III-l. 


FEASIBILITY - >  ANALYSIS - >  DESIGN - > 

PROGRAMMING - >  TESTING 

Figure  III-l.  Tvpical  Stages  of  System  Development 

Feasibility  is  determined  by  'management*  (the  administration  in 
AFIT's  case)  to  insure  that  the  proposed  system  is  both  desired  and 
feasible.  This  takes  into  account  such  items  as  the  irrportance  of  the 
effort  to  the  school,  projected  hardware  and  software  reqtTirerrents,  the 
time  and  people  resources  required,  as  well  as  other  factors.  Once  this 
receives  a  'go'  decision,  the  more  detailed  analysis  stage  begins. 

The  analysis  stage  involves  determination  and  definition  of  the 
user's  data  and  processing  requirements.  The  user's  information  model 
(definition  of  data  items  and  groups  and  function,  definition  of  input 
to  the  system,  output  from  the  system,  and  how  data  is  manipulated)  is 
specified. 

The  design  stage  then  transforms  the  information  imodel  and  function 
into  a  format  from  which  programs  can  be  written.  This  process  involves 
defining  the  data  to  the  database  nonagement  system  (i.e.,  converting 
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the  beginning  or  the  end  of  a  chciin)  or  a  relative  location  can  be 
specified  for  retrieval. 


All  data  entry,  update,  and  deletion  operations  are  performed  by 
the  CALL  facility  of  the  DEL  in  TOTAL.  Records  added  to  a  single-entry 
file  are  mapped  into  a  data  space  on  the  basis  of  their  key  values. 
Records  added  to  a  variable-entry  file  may  be  appended  either  to  the 
beginning  or  the  end  of  a  chain  of  inserted  within  the  chain. 

Update  facilities  for  both  file  types  are  similar.  Each  has  a 
single  write  cotmand  for  logical  record  access.  TOTAL  provides  Macro 
calls  to  search  single-entry  files  either  by  key  or  serially  frcm  a 
efined  record  position;  by  linkage-path  chains,  in  the  case  of 
variable-entry  files.  In  addition  to  these  logical  update  facilities, 
a  variable-entry  file  may  be  updated  serially. 

Records  may  be  deleted  from  either  type  of  files.  In  both  cases, 
the  deleted  record's  space  beccmes  immediately  available  for  reuse. 
However,  all  variable-entry  records  linked  to  the  single-entry  record 
being  deleted  must  be  individually  deleted  prior  to  deletion  of  the 
master  record.  This  protects  the  records  in  the  variable-entry  file 
from  being  orphaned  by  the  deletion  of  a  master  record. 

Application  Flexibility 

TOTAL  file  organization  is  ideal  in  an  application  environment  in 
which  serial  processing  of  small  groups  of  records  with  cannon  key  val¬ 
ues  is  required,  since  keys  other  than  the  master  key  in  the  single¬ 
entry  record  may  be  used  as  the  basis  for  linkage  paths  in  the  variable 
entry  files,  i.e.,  in  AFITDB,  if  a  single-entry  key  is  SSN  then  the 


set  of  all  associated  records  in  a  variable-entry  file  has  a  particular 
SSN  in  cannon;  hence  are  chained  in  a  list.  This  feature  is  well 
suited  to  satisfying  query  conjunctions  under  certain  sets  of  condi¬ 
tions. 

File  Maintenance 

TOTAL  performs  several  file  maintenance  activities  in  the  AFITDB 
viiich  are  transparent  to  the  user.  These  include  chain  counts,  pointer 
control,  and  key  creation  or  deletion.  These  controls  ensure  that  the 
single-entry  and  variable-entry  files  retain  their  ccrpatibility  and 
that  established  chain  linkages  are  not  broken. 

Whenever  a  record  is  added  to  a  variable-entry  file,  several 
events  occur.  First,  the  new  record  is  physically  added  to  the  file. 
Each  master  file  linked  to  the  detail  file  is  checked  to  see  if  the  key 
value  already  exists.  If  it  does  not,  the  key  value  is  added  to  the 
single-entry  file.  The  counter  is  set  to  1  and  both  forward  and  back¬ 
ward  pointers  are  initialized  to  be  the  address  of  the  new  record.  If 
the  key  already  exists  on  the  master  file,  the  counter  is  increnented. 

If  the  record  is  to  be  added  at  the  chain's  end,  the  backward  pointer  is 
used  to  access  the  current  last  record  of  the  chain.  Its  forward 
pointer  is  set  to  be  the  address  of  the  new  record.  The  master  record 
is  also  updated  with  the  backward  pointer  holding  the  address  of  the  new 
record  (now  the  last  one  on  the  chain) .  The  new  record's  backward 
pointer  is  set  to  the  old  last  record.  If  the  record  is  added  to  the 
middle  of  the  chain,  the  master  record's  pointers  remain  unchanged.  The 
new  record  reflects  both  forward  and  backward  pointers.  The  record 


preceeding  and  the  record  following  the  new  records  are  changed  to 
point  either  forward  to  or  backward  at  the  new  record. 

When  records  are  deleted,  these  steps  are  reversed  including  de¬ 
creasing  the  chain  count  and  resetting  either  master  or  other  chain 
members  forwcird  and  backward  pointers.  If  a  single-entry  file  is  used 
only  as  a  key  file  (no  data)  and  all  of  the  counters  are  reduced  to 
zero,  that  is  there  are  no  chains,  then  the  master  record  is  removed 
from  the  single-entry  file.  It  is  not  possible  to  remove  this  record 
as  Icaig  as  the  counters  sum  to  greater  than  zero. 

TOTAL  Opportunities 

Beyond  the  basic  TOTAL  characteristics,  this  package  offers  several 
opportunities  for  creative  design.  These  include  single-entry  files 
with  data,  coded  records,  and  multiple  access  paths. 

Single-entry  files  always  contain  a  unique  key  value.  The  records 
are  located  by  a  randotiization  of  the  key  value.  Data  may  be  stored 
xvith  the  key  if  certain  conditions  exist: 

1.  Data  has  one-to-one  correspondence  with  the  key 

2.  Data  is  not  desired  by  an  alternative  key 

3.  Data  usually  occurs  for  the  key. 

If  data  is  stored  with  the  key,  the  information  is  available  to  the 
program  sinply  by  locating  the  single-entry  record  by  randanizing.  In 
those  cases  where  this  approach  is  feasible,  it  will  reduce  the  I/O 
necessary  to  obtain  the  non-key  data. 

Variable-entry  files  may  contain  one  type  of  record  or  several. 


If  several  different  record  formats  appear  in  one  file,  they  are 


distinguished  by  a  t^i'pe  ccxie.  Therefore y  these  records  are  called 
coded  records.  Coded  records  are  a  fixed  length  as  are  all  variable- 
entry  records.  If  record  formats  differ  in  length,  then  sane  disk 
space  will  be  lost.  The  advantages  of  coded  records  are: 

1.  Records  of  one  key  grouped  together 

2.  Reducticn  in  I/O 

3.  Ability  to  obtain  one  record  by  a  coded  read 

4.  Sirrplification  of  databcise  design. 

Records  of  different  types  could  be  placed  in  different  variable- 
entry  files,  however,  placement  in  one  file  allows  all  records  for  a 
given  key  to  be  grouped  together.  When  these  records  occupy  contiguous 
areas  in  a  block,  the  I/O  activity  will  be  reduced.  I/O  activity  is 
also  reduced  by  eliminating  the  need  to  go  to  the  single-entry  file  to 
pick  up  additional  chains  to  follcw.  Records  for  one  key  vhich  are 
grouped  together  are  not  always  desired  ^  a  group.  TOTAL  has  a  tech¬ 
nique  called  a  coded  read  which  allows  the  application  to  select  only 
those  records  of  a  certain  type. 

The  DBMS  provides  opportunities  for  multiple  access  paths  into  the 
variable-entry  data  records.  Any  field  has  the  potential  to  be  a  key. 
This  provides  flexibility  in  programming  batch  applications  and  in  on¬ 
line  inquiry.  The  inquiries  can  use  the  key  which  will  most  quickly 
provide  the  information  required.  The  batch  programs  can  use  alternate 
keys  to  reduce  sorting.  Secondaury  keys  also  provide  access  when  the 
primary  key  is  unknown.  While  every  field  may  be  a  key,  it  is  not 
desirable  to  have  all  fields  as  keys.  If  there  is  little  probability 
that  the  data  element  will  be  used  as  an  access  path  for  batch  or 


— 


cxi-line  programs,  then  it  should  not  be  a  key.  There  is  an  overhead 
cost  associated  with  the  addition  of  keys  both  in  terms  of  disk  stor¬ 
age  cost  and  additional  file  maintenance.  Every  key  requires  a  single¬ 
entry  file  to  hold  the  key,  its  pointers  and  chain  counter.  Thus,  this 
project  determined  keys  using  the  relational  Third  Normal  Form  tech¬ 
nique,  to  assist  in  insuring  that  such  items  as  student  social  security 
number  rather  than  course  number  were  utilized  to  find  a  specific 
individual's  education  plan. 

TOTAL  Limitations 

The  DBMS  does  have  limitations  as  itemized  below.  While  the  list 
of  limitations  appears  lengthy,  it  should  be  remembered  that  a  limita¬ 
tion  is  not  a  liability  if  the  system  being  designed  does  not  require 
that  particular  function.  Limitations  of  TOTAL  are: 

1.  Overhead  in  disk  storage  due  to  pointers,  counters,  keys 
and  single-entry  files. 

2.  Overhead  in  production  time,  expended  to  maintain  pointers 
and  single-entry  files. 

3.  Inability  to  model  deep  hierarchies. 

4.  Requirement  of  fixed- length  records. 

5.  Difficulty  of  generic,  or  stem,  searches. 

6.  Disallowal  of  embedded  or  concatenated  keys. 

Overhead  in  TOTAL,  as  in  any  DBMS,  is  higher  than  for  sequential  or 
randan  files.  Additional  disk  storage  is  required  for  the  single-entry 
files  vdiich  is  a  repetition  of  the  key  plus  a  pointer  field  and  chain 
length  counter  for  each  chain  into  variable-entry  files.  Records 
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viiich  repeat  occurences  on  a  variable- length  record  niust  repeat  the  key 
with  each  record  occurence  vrtien  napped  to  a  variable-entry  file.  The 
variable-entry  files  also  must  contain  pointer  fields  for  every  chain 
viiich  the  record  is  on.  Additional  disk  storage  may  also  be  required 
for  coded  records  which  vary  in  length. 

TOTAL  also  has  overhead  in  processing  time  due  to  file  maintenance. 
Whenever  records  are  added,  deleted,  or  changed,  pointers,  counters, 
and  key  files  are  also  affected.  Retrieval  of  the  affected  records  in 
addition  to  the  actual  change  and  rewrite  costs  additional  time  in  pro¬ 
cessing.  The  overhead  issue  is  not  unique  to  TOTAL  and  is,  in  fact,  a 
universal  problem  with  DBMSs.  The  other  dravtoacks  are  characteristic 
of  DBMS,  which  have  a  network  approach. 

TOTAL  models  pcirent-child  relationships  very  nicely  with  the 
single-entry  and  variable-entry  files.  Deeper  hierarchies  than  this 
are  difficult  to  model.  During  the  design  phase  of  this  project,  no 
cases  requiring  more  than  a  two-level  hierarchy  were  determined. 

TOTAL  requires  that  all  records  in  both  the  single  and  variable- 
entry  files  be  fixed-length.  Stem  searches  are  not  possible  with  TOTAL 
directly.  A  stam  search  uses  only  a  partial  key  and  retrieves  all 
key  chains  associated  with  the  partial  key.  Due  to  the  randomization 
of  the  key  for  placing  the  data  in  the  single-entry  file,  it  is  highly 
unlikely  that  adjacent  records  are  in  sequential  order.  Sequential 
order  in  the  key  file  is  required  to  allow  a  generic  search.  If  it  is 
necessary,  the  pr(±)lem  does  have  a  resolution.  In  addition  to  keeping 
the  keys  on  a  single-entry  file,  they  should  also  be  on  a  VSAM  (or 
other  indexed  type)  file.  The  only  data  on  the  file  would  be  the  key. 


When  a  stem  seeirch  was  required,  it  would  be  performsd  on  this  indexed 
file.  All  records  retrieved  would  then  be  lised  as  a  whole  key  in  the 
database.  This  process  takes  longer  and  has  some  other  dravfcacks. 

The  additional  file  requires  file  maintenance  in  the  programs  for  up¬ 
dates,  adds,  and  deletes.  This  is  not  autanatic  in  the  DBMS.  The  file 
also  requires  additional  space.  There  is  the  added  problem  of  main¬ 
taining  ccnpatibility  between  the  indexed  file  and  the  database. 

This  ^proach  will  solve  the  problem  but  should  not  be  irrplemented 
unless  absolutely  necessary.  Figure  IV-3  illustrates  this  process. 

TOTAL  also  does  not  allow  embedded  or  concatenated  keys.  This 
means  that  the  last  four  digits  of  the  individuals  SSN,  if  used  as  a 
key  elsevdiere,  cannot  be  used  as  a  key  if  SSN  is  also  a  key.  This 
problem  is  solved  by  repeating  the  Icist  four  digits  as  a  separate  field 
if  both  paths  are  necessary.  Concatenated  keys  would  be  a  combination 
of  two  fields  such  as  SSN  and  DOB.  This  problem  also  can  be  solved  if 
need  be  by  repetition  of  data  in  each  variable-entry  record  (18:3-11) . 

Data-Set  Selection 

The  data  items  determined  from  tte  interviews  were  selected  and 
grouped  as  either  master  or  vcuriable  data.  Master  corresponded  to 
itans  vdiich  tended  to  be  less  dependent  on  change  (like  course  name, 
course  number,  SSN  and  student  name)  while  variable  tended  to  pertain 
to  items  less  resistant  to  change  and  items  determined  by  application 
process  not  requiring  or  unable  to  be  kept  permanently  (like  a  student' 
selected  courses  which  may  change  each  quarter) . 


The  stem  SMITH  results  in  selecting 
SMITH,  SMITHFIELD,  and  SMITHSCN  from 
the  indexed  file. 


Variable-entry 

File 


Single-entry  File 

The  v^le  name  is  used  as  a  key  into  a  single¬ 
entry  file  and  the  chain  to  its  variable-entry 
file  is  followed  as  in  the  usual  process. 


Figure  IV- 3.  Stem  Search  Lfiider  TOTAL 
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Appendix  F  lists  the  specific  requirements  from  the  directed 
interviews  (on  the  left  side) ,  with  the  subsequent  location  for  the 
inclusion  of  this  data  in  the  Data  Definition  Language  expanded  data- 
bcise  generation  directly  opposite  (cxi  the  right  side) .  It  is  a  refine¬ 
ment  of  those  items,  thought  to  be  candidates  for  inclusion  in  the  data¬ 
base,  form  interviews  (i^jpendix  D) ,  and  those  items  already  existing 
in  the  database  (Appendix  E)  .  The  items  in  Appendix  G  were  not 
necessarily  requested  through  interviev«,  but  added  by  the  designer  for 
anticipated  use  by  tlie  database.  Items  such  as  the  'Expected  AFIT 
Departure  Date'  of  a  Faculty  member  and  vdiich  courses  belong  to  a 
particular  course  sequence  were  envisioned  to  greatly  assist  the 
Administration  in  future  database  requests.  It  must  be  pointed  out  that 
although  the  interview  technique  was  conducted  to  gain  iitportant  guide¬ 
lines  and  insight,  relying  too  heavily  on  it  would  create  the  same  type 
pitfall  as  simply  utilizing  data  items  already  contained  in  the  data¬ 
base  (see  page  4-1) . 

Likewise,  due  to  the  synergistic  result  from  conments  of  the  Data¬ 
base  Administrator  (DBA) ,  supervisors  and  users  alike,  continued  changes 
to  the  design  yet  occurred.  As  an  example,  rather  than  have  two 
separate  variable  data-set  files  for  student  and  faculty  Education 
History,  a  combined  data-set  was  established  (built) .  The  same  proce¬ 
dure  was  done  for  Awards.  This  action  was  taken  to  reduce  the  number  of 
data-sets  in  the  database,  since  the  anticipated  number  of  items  versus 
their  frequency  of  access  was  deemed  low. 


Anticipated  Application  Programs 

Appendix  D  lists  the  major  response  areas  determined  by  the  inter¬ 
view  process  and  depicts  their  priority  for  database  development. 
Ccmbining  Afpendix  E,  the  original  AFITDB  data-set  items/  and  Appendix 
F,  the  listing  containing  which  new  data-sets  fulfill  the  proposed 
expanded  database  requirements  produced  the  anticipated  requirements 
for  application  programs  as  specified  in  Appendix  H.  Each  requirements 
presentations  item  subheading  is  further  divided  into  specific  antici¬ 
pated  application  programs  to  fulfill  the  listed  requirements.  These 
guidelines  encourage  better  program  database  interaction  prcamising  siab- 
stantially  more  coctprehensive  and  viable  database  utilities  for  use  by 
the  Depcirtment  of  Electrical  Engineering  and  AFIT. 

Data  Definition  Language 

After  Stage  One  of  the  Design  process  is  cctrpleted,  the  work  of 
structuring  the  Data  Definition  Language  takes  place.  The  collection 
of  information  that  describes  the  database,  when  organized  in  a  formal 
manner,  is  called  the  schema.  Data-elerrent  descriptions  are  an  iitpor- 
tant  pcirt  of  the  schema. 

A  set  of  docijments  that  is  used  by  a  progranming  staff  to  generate 
programs  could  be  viewed  as  a  schona.  Programmers  will  perform  an 
analysis  of  the  tasks  and  consider  the  available  data  elements.  Sub¬ 
sequently  they  can  code  the  required  programs.  Many  statistical  systems 
have  provided  directory  facilities  with  their  data  files,  so  that  the 
collected  observations  will  always  be  properly  identified  and  titled. 


4-20 


Figure  IV-4  places  the  idea  of  a  schana  in  perspective.  The 
schema  is  used  both  to  place  inconing  data  properly  into  the  files  and 
to  locate  requested  data  at  a  later  time.  The  dictionaries  in  the 
schema  aid  the  users  in  describing  their  requests,  and  perform  a  filter¬ 
ing  function  to  improve  data  quality  within  the  database.  The  descrip¬ 
tion  of  the  database  using  the  schema  precedes  the  use  of  the  database. 
E)atabase  users  usually  do  not  (nor  should  they)  have  the  capability  to 
modify  the  schema  during  database  operaticais.  In  order  to  create  a 
schema  a  language  facility  sepcirate  fran  that  vhich  is  used  vdien 
manipulating  an  existing  database  (14:377)  is  usually  required. 

In  the  TOTAL  OEMS,  the  DDL  outlines  and  defines  space  for  the 
inclusion  of  data  into  the  database.  It  also  outlines  the  links  among 
data  sets  and  is  the  'schematic'  for  the  database  as  well.  For  this 
recison,  a  schematic  was  constructed  to  keep  track,  not  only  of 
individual  data-sets,  but  also  their  numerous  links,  while  relating 
atomic  values  with  proposed  application  program  requirements.  Figure 
IV-5  depicts  the  AFIT  Database  prior  to  the  revision  and  update 
acconplished  by  this  project.  The  resultant  schema  (Figures  IV-6(1)  - 
IV-6(3))  depicts  the  expanded  AFIT  Database  ais  well  as  the  many  data-sets 
and  links  to  data-sets. 

Database  Descriptor  Module 

Utilizing  this  schema  and  the  DBMS  (TOTAL)  DBI^OD  utility,  DBGEN,  a 
Database  Descriptor  Module  (DBMC®)  was  generated.  The  DBGEN  utility 
reads  the  Database  Descriptor  Language  (DBDL)  statements,  and  generates 
the  source  program.  The  DBMOD  object  file  is  provided  after  assembling 


Rejects 

Data  Entry 


Data  Retrieval 


Database  System 


Figure  IV-4.  TTie  place  of  a  Schoia  in  Input  and  Output 
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the  area  it  represents  and  provides  a  further  definition  to  the  user 
of  the  screens  from  which  he  is  expected  to  choose.  The  user  then 
selects  the  next  data-input  screen  corresponding  to  the  specific  data 
required  for  input  or  viewing.  The  approxiniate  screen  corresponding 
with  his  selection  is  then  displayed  and  the  terminal  remains  open  col¬ 
lecting  input.  The  method  utilized  to  move  around  within  an  BTVIS  screen 
is  by  use  of  the  'Tab'  and  'Backspace'  keys.  The  'Tab'  advances  the 
cursor  from  field  to  field  vhile  the  'Backspace*  key  backs  up  the  cursor 
frcm  field  to  field.  Other  keys,  like  'Delete'  (which  removes  characters 
from  the  display)  and  the  arrow  keys  (v^ch  move  the  cursor  in  the  direc¬ 
tion  of  the  arrow  within  a  field)  are  obvious,  while  the  'Linefeed'  key 
is  not  (it  blanks  the  entire  field) .  Further  specifics  can  be  found  in 
the  VAX-11  Software  Reference  Manual  (19) . 

The  Driver  was  developed  with  not  only  professors/ instructors  or 
students  envisioned  as  users,  but  also  the  secretary  charged  with  imput¬ 
ing  all  the  initial  data  and  subsequent  updates.  This  can  be  a  tedious 
undertaking  for  the  secretary.  Therefore,  after  the  last  screen  for  the 
chosen  area  has  been  exited  (sane  areas  call  for  more  than  one  screen  to 
be  displayed  in  succession)  ,  a  final  screen  is  displayed  which  prorrpts 
the  user  to  choose  among  three  choices. 

1.  Input  additional  data  utilizing  the  last  series  of  screen (s) 

2.  Return  to  the  previous  (last)  menu  displayed 

3.  Exit  the  program  (Figure  V-4)  . 

The  choice  of  entering  additional  data  closes  the  previous  data 
input  file  prior  to  opening  a  new  file  for  the  additional  input.  Pro¬ 
gram  'Driver'  does  have  the  option  to  exit  at  the  'FIRSTl'  screen,  but 
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Data 


AFITDB  DEMONSTRATICN  MENU 


Initial  Menu  Screen 


Nowhere  in  the  reference  material  is  this  most  inportant  fact 
listed. 

Form  Driver  Library 

The  Form  Library,  AFrrLIB2.FLB  (Appendix  I) ,  was  designed  bo  hold 
menu  and  data  display/collection  screens  patterned  after  the  Schona  for 
the  expanded  database.  The  first  screen  is  'AFITl'  (Figure  V-1)  which 
is  an  introduction  screen  and  cisks  for  a  choice  to  input  data,  use 
utilities,  or  exit.  Since  the  screen  was  designed  with  an  expanded  data¬ 
base  in  mind,  the  first  two  options  call  the  same  next  screen,  'BEGIN'. 
This  screen  can  be  used  to  check  user  security,  if  desired,  or  to  pro¬ 
hibit  the  user  frcm  advancing  into  the  database  any  further. 

The  next  screen,  'FIRSTl',  is  the  first  real  user  menu.  Here  the 
user  may  make  one  of  seven  choices: 

1.  Faculty  (Personal  information,  interests,  TDY,  Professional 
Societies,  Catmittee's,  Publications  and  Presentations). 

2.  Student  (Personal  Information,  Courses  in  Education  Plan, 

Thesis  Information) . 

3 .  Student/Faculty  (Education  History  or  Honors /Awards) . 

4.  Textbook  Information. 

5.  Scheduling  Information. 

6.  Other  Master  Entry  Data. 

7.  Utilities  (Ed  Plan,  Degree  Requirements,  Student  Graduate 
Credit  Record  Form  (Form  89))  (Figure  V-2) . 

A  choice  of  any  of  these  screens  will  cause  that  menu  screen  for 
the  chosen  area  to  ^pear  (Figure  V-3) .  Each  menu  screen  announces 
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a  major  time  consuming  effort  because  of  the  unavailable 
PASCAL  EMS  documentation  and  VAX/VMS  EWS  version  update 
required  to  build  and  run  a  self-contained  and  directly 
EMS-related  structure. 

4.  Debug  Program  with  Forms  -  This  followed  the  necessary 
work  to  incorporate  the  ability  to  capture  data  input 
and  retrieve  data  through  the  DBMS  and  the  operating  system. 
Existing  application  programs  \^re  modified  to  accept  this 
utility,  vdiich  required  conpatibility  debugging. 

Initially,  a  number  of  forms  were  created  for  use  with  the 
expanded  AFIT  database  and  placed  within  a  library,  AFITLIB2.FLB 
(Appendix  I) ,  for  use  with  the  'Driver'  routine  to  test  both  the  form 
capability  and  the  unique  call  requirements.  This  test-bed  was  in¬ 
valuable  for  determining  inconsistencies  v^iich  resulted  by  using  the 
reference  material  and  provided  exanples.  For  example,  the  reference 
states  that  for  the  specific  call  'FDV$NDATA' ,  the  call  "...is  used 
to  access  by  name  data  that  has  previously  been  associated  with  a  form 
as  named  data"  (20:6-13) .  An  example  of  this  call  as  used  in  an 
example  program  is  (the  FCRTE?AN  statement):  'IF  (FDV$NDATA  (RESP, 
FOE^M)  .GT.  1)  GO  TO  90'  (20;A-16) .  It  was  not  until  later  that  it  was 
discovered  that  this  call  does  not  return  a  value  unless  specified 
by  yet  another  call  and  that  value  is  EMS  specific  (which  is  related 
to  a  predefined  error  coding  which  can  be  a  positive  or  negative 
number)  (20:5-3) .  To  effectively  use  this  call,  the  value  returned 
must  be  used  as  a  Boolean,  and  cannot  be  used  to  corpare  values. 


Chapter  5 


V.  AFIT/E^G  Databcise  Design/Iirplementation 

This  chapter  will  highlight  the  remaining  stages  within  the  Soft¬ 
ware  Development  Life  Cycle  as  pertain  to  this  project.  The  integra¬ 
tion  of  the  database  design  with  that  of  the  coding  and  unique  display 
technique  will  be  explained  in  detail.  Additional  stages  in  the  Soft- 
;^are  Development  Life  Cycle,  from  coding  through  testing,  integration, 
and  acceptance  testing,  will  be  highlighted  to  show  the  transition  with¬ 
in  the  effort. 

Utlizing 

A  short  development  cycle  for  the  inclusion  of  this  utility  with 
the  database  had  four  stages: 

1.  Plan  -  This  was  usually  short,  since  the  initial  database 
design  fairly  determined  the  format  for  the  form.  Determining 
the  atomic  values  tended  to  outline  this  most  accurately. 

2.  Design  Forms  -  This  stage  followed  directly  after  the  Planning 
stage,  and  was  determined  quickly  due  to  the  planning  stage 
rationale . 

3.  Write  and  Document  Program  -  The  initial  work  done  was  to 
develop  a  trial  Driver  to  insure  understaiiding  of  the 
specific  conmands  and  their  relationship  with  the 
programming  language.  Additionally,  ccsipatibility  experimen¬ 
tation  wcis  required  to  be  conducted  to  also  determine  the 
means  required  to  interface  with  the  DBMS.  This  became 


(item  5)  and  service  (item  7) ,  precede  the  student's  place  of  birth 
(item  22)  and  his  previous  conmand  (item  28) ,  vdiich  will  not  con¬ 
ceivably  change  while  at  AFIT.  More  specific  data  on  FMS  is  contained 
in  i^jpendix  0. 

Sunmary 

This  chapter  characteri2ed  the  TOTAL  network  DBMS  and  its  cap¬ 
abilities  and  limitations,  the  Data  Definition  Language  (DDL) ,  the 
design  settled  upon  for  the  schema  and  data-sets,  and  provided  an  over¬ 
view  of  the  Form  Management  System  (EMS) .  The  time  spent  on  the  many 
design  revisions  and  structuring  required  for  the  DDL  and  schema  pay 
dividends  later  in  the  project.  Although  minor  revisions  continued  to 
occur  as  additional  data  was  included  in  the  project,  these  were  minor 
because  of  the  in-depth  analysis  already  carpleted.  As  in  the  Software 
Development  Life  Cycle,  as  integration  of  the  project  parts  occurs,  the 
worth  of  the  design  stage  is  borne  out,  for  the  errors  introduced  in 
the  design  stage  are  detected  in  the  integration  stage. 


Figure  IV-7.  Student  Personal  History  Data 
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Therefore,  menus  were  selected  as  the  most  user  friendly  mode  of 
operation  for  both  data  input  and  retrieval. 

An  available  utility  on  the  existing  hardware  is  the  software 

•'i 

package  from  Digital  Equipment  Corporation  (DEC) ,  the  Form  Managenent 

Systan  (BMS) .  It  is  designed  for  ease  of  formulation  and  form  siitula-  .  a 

tion  in  order  to  collect  the  transmit  data  in  an  orderly  manner.  Forms  1 

are  designed  by  typing  them  directly  cxito  the  terminal  screen.  Neither  ^ 

layout  charts  nor  a  special  forms  design  language  is  required.  ET'^  ; 

associates  constant  data  with  the  form,  not  with  the  application  pro¬ 
gram,  resulting  in  syrplified  application  program  maintenance  and 

•1 

increased  application  program  flexibility.  Forms  may  later  be  modified  ^  j 

without  the  need  to  recorpile  the  application  program  (as  long  as  the 
form  does  not  change  application  program  specific  areas) .  This 
utility  supports  any  language  supported  by  the  VAXA^  host  ccrputer. 

The  order  of  the  data  contained  on  the.FMS  screens  is  determined 
by  grouping  data  items  by  category,  and,  to  a  lesser  extent,  by  screen 
requirements.  Each  screen  was  created  to  present  cohesive  areas  for 
data  input  and  to  make  judicious  use  of  limited  space.  Screen  require¬ 
ments  pertain  to  the  data  collection  precedence  with  the  FMS  (top-to-  - 

bottom  and  left-to-right) .  In  an  effort  to  show  all  personal  data  on 
the  CRT  screen  at  once  without  having  to  scroll  through  an  area  to  see 
it  all,  the  selected  option  was  to  forego  the  use  of  scroll  areas.  All 
personal  data  is  still  grouped  by  category.  For  exanple,  see  Figure 
IV-7.  The  most  often  accessed  student  data  precedes  the  data  less 

often  changed  to  acccmnodate  the  anticipated  changes  required  to  be  per-  ■ 

formed  by  the  user  (secretary,  student,  etc.).  Thus,  a  student's  rank 
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space  allcx:ated  for  user  use  would  be  less  than  calculated.  He  also 
provided  a  means  to  determine  the  size  of  the  schema  vdiich  can  be  found 
as  an  octal  number  at  the  end  of  the  .LST  listing  after  the  schema  is 
cotpiled.  Converting  the  octal  nxmber  to  decimal  and  dividing  by  two 
gives  the  size  in  words  vMch  can  then  be  ccnpared  to  the  maximum  per¬ 
missible  size  minus  the  given  TOTAL  restraints,  above.  For  this  pro¬ 
ject,  the  additional  work-space  areas  were  deleted  in  order  to  validate 
the  schema  and  test  the  EWS  and  application  program  integration. 
Subsequent  revisions  on  the  size  of  the  database  verified  that  at  max¬ 
imum  size,  only  a  few  axiditional  work-sapce  areas  would  need  to  be 
deleted  (see  Chapter  6,  Recotmendations) . 

Form  Managenent  System 

Along  with  the  database  design,  and  the  use  of  the  DBMS  to  act  on 
the  data,  application  programs  to  manipulate  the  database  are  required. 
With  this  goes  the  task  of  interfacing  such  applications  programs  (and 
database)  with  the  user.  Inasmuch  as  the  design  of  this  database  and 
its  use  is  for  the  present  as  well  as  the  future,  it  was  felt  that 
utilizing  an  enhanced  data  presentation  utility  would  further  the  use¬ 
fulness  of  this  database. 

The  main  thrust  of  this  database  is  storing  and  retrieving  data 
items  involving  individual  student  and  faculty  personal  history  as  well 
as  student  education  planning.  The  interviev;s  pointed  out  the  large 
volumes  of  data  required  to  be  input  with  the  start  of  each  new  class, 
subsequent  course  scheduling,  as  well  as  requested  utilities  designed 
to  make  use  of  the  expanded  database  to  a  degree  previously  unable. 


this  source  program.  The  DBMOD  is  now  available  for  use  with  TOTAL 
and  its  utilities  (6:3-4) . 

The  size  of  the  DBMOD  was  determined,  initially,  by  the  design  of 
the  schema.  This  design  included  additional  workspace  areas  to  permit 
the  multi-user  operation  of  the  TOTAL  database.  However,  each  time  the 
DBMCO  utility  Weis  utilized  with  this  schema,  an  error  code  correspond¬ 
ing  to  a  size  limitation  was  displayed.  A  literature  search  did  not 
alter  this  continued  error  display,  and  a  telephone  call  to  CINCXDiyi,  the 
TOTAL  developers,  finally  obtained  a  solution. 

Although  the  TOTAL  installation  documentation  (6:2-17)  states  that 
the  maximum  extmod  size  is  32768  words,  it  does  not  state  how  users  may 
find  the  size  of  their  proposed  database  schema.  The  size  required  by 
TOTAL  is  10,800  words  with  any  logging  options  and  connunication 
buffers  each  requiring  a  specified  amount.  This  total  subtracted  from 
the  maximum,  based  on  the  documentation,  should  show  the  maximum  user 
schema  size.  Each  time  the  size  error  occurred,  the  TOTAL  installation 
procedure  was  re-initiated  in  order  to  enlarge  the  extmod  space.  The 
additional  size  requirement  was  added  to  the  last  extmod  size  to  arrive 
at  the  needed  amount.  However,  entries  of  values  greater  than  the 
default  value  specified  (later  determined  to  be  the  maximum  accepted) , 
generated  the  default  value  used  as  the  extmod  size. 

The  CINCCM  software  representative  (17)  explained  that  TOTAL  can 
only  handle  a  size  limitation  as  outlined  in  the  installation  guide  and 
even  the  newest  version,  yet  to  be  released,  would  only  expand  this 
size  limitation  very  little.  However,  he  also  stated  that  since  the 
AFIT  version  of  TOTAL  included  software  patches,  that  the  available 
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Figure  V-4.  Last  Menu  Screen 


does  not  allow  the  user  to  back  up  past  this  screen,  since  screens 
prior  to  this  are  for  entering  the  database  only. 

I'^hen  'EXIT'  is  the  elected  option  by  the  user,  a  number  of  things 
transparent  to  the  user  happen.  Since  this  option  resides  on  a  number 
of  screens,  exiting  during  a  reverse  video  displayed  screen  would  cause 
the  users  terminal  to  remain  reverse  video.  Through  a  short  routine, 
vhen  exiting  normally,  the  screen  autanatically  defaults  to  black 
background,  the  screen  is  cleared,  and  the  cursor  is  placed  in  the  heme 
position. 

Appendix  I  lists  the  screens  contained  within  the  library.  Not 
shown  in  i^pendix  I  are  continuation  screens  for  Graduate  Credit  Record 
Form  (Figure  1-35)  and  Student  Education  Plan  Form  (Figure  1-32) . 

Driver  Program 

It  was  essential  that  prior  to  juirping  into  designing  application 
programs  to  pass  data  between  the  database  and  the  user,  that  the 
ability  to  determine  how  this  must  be  accctrplished  would  first  be 
determined.  This,  the  FED  and  FUT  were  used  in  conjunction  with  pro¬ 
ducing  a  program  able  to  call  each  form  in  the  library  and  pass  data. 

The  first  step  was  to  achieve  a  working  Driver  program  to  display 
forms  and  input  data.  Another  problem  arose  at  this  point.  Because  no 
documentation  was  available  to  provide  assistance  as  to  the  proper  han¬ 
dling  of  parameters  in  PASCAL,  the  Driver  had  to  be  written  in  a  lan¬ 
guage  supported  by  some  available  documentation.  FORTRAN  was  chosen  be¬ 
cause  of  its  similarity  to  PASCAL.  By  utilizing  the  provided  model  (20) , 
and  example  FORTRAN  program  (20:A-15) ,  the  'Driver'  program  was  written 


(in  POR'IRAN)  with  its  purpose  to  display  each  form  in  the  library  (see 
page  5-2)  .  After  determining  how  each  Form  Driver  call  both  passed  and 
received  data,  the  Driver  program  was  able  to  function  as  designed. 
Problems  in  working  through  program  discrepancies  aided  in  establishing 
vdiat  parameters  would  be  required  in  adapting  this  test  program  to  a 
working  database  application  program  (see  page  5-3) .  Such  coding  and 
testing  preceded  the  integration  of  the  utilities  with  the  operation 
of  the  database,  vdiich  cctnplied  with  following  the  software  life  cycle 
development. 

The  next  step  was  to  achieve  the  display  of  'old'  data  (pre¬ 
viously  written  to  a  file)  from  a  file  to  a  displayed  form  utilizing 
more  Form  Driver  calls.  This  became  a  replay  of  the  techniques  learned 
from  the  first  step  (above) ,  and  was  necessitated  by  the  lack  of  docu¬ 
mentation  and  errors  in  existing  exanples.  This  step  was  the  logical 
extention  of  the  first  to  determine  the  techniques  required  to  infuse 
the  EMS  operation  with  the  DBMS.  This  progam  was  called  'Input'.  The 
major  problems  centered  around  retrieving  data  previously  written  to 
an  external  file,  retrieving  the  data  within  the  file  and  assigning 
the  fields  within  this  file  for  display  through  the  proper  screen. 

This  test  program,  also  done  in  FORTRAN,  proved  that  the  VMS  calls 
properly  functioned  as  intended. 

The  third  step  became  a  series  of  proofs  for  eventual  Form  Util¬ 
ity  inclusion  with  the  DBMS.  The  new  database  structure  schema  had  al¬ 
ready  been  designed  and  the  Database  Descriptor  Module  (DBMOD)  generated 
utilizing  the  TOTAL  DBMS  DBGEN  utility  (see  Chapter  4).  The  order  of  the 


data-sets  within  the  database  generation  schena  show  the  master  data¬ 
sets  followed  by  the  variable  data-sets.  This  was  necessary  because  any 
references  to  the  rtaster  data-sets  were  required  to  first  insure  that 
the  master  data-set  be  known  to  the  DBGHJ  utility.  Thus,  all  master 
data-sets  precede  any  references  to  the  variables.  There  is  not  the 
same  requirement  that  variables  precede  any  other  variables  that  they 
may  reference. 

At  this  point  the  DBMOD  was  initialized  and  data  loaded  into  it 
in  order  to  insure  that  this  most  important  portion  of  the  project 
functioned.  Application  programs  which  functioned  witli  the  currently 
used  database  were  run  utilizing  this  new,  upgraded  database  version. 

Data  was  successfully  stored  and  the  application  programs  adequately  run 
with  them.  This  effort  was  temporarily  suspended  to  determine  v^ether 
the  expanded  AFIT  database,  previously  created  and  compiled,  would 
function  as  designed  with  the  redesigned  and  rewritten  application 
programs.  The  emphasis  was  placed  on  proving  that  the  database  would 
accept,  retain,  and  output  data. 

Three  application  programs  (NSTUDENT.PAS,  COURSE. PAS,  and 
INPUTFACT.PAS) ,  which  functioned  properly  utilizing  the  original  AFIT 
database,  were  slightly  modified  in  order  to  test  their  ability  to  obtain 
identical  results  using  the  the  expanded  database.  The  application  pro¬ 
grams  were  modified  to  display  the  FMS  form  screens  previously  created 
to  determine  what  modifications  would  have  to  be  made  to  incorporate  the 
form  utility  within  the  existing  application  programs  and  TOTAL  Database. 
Using  the  itxDdified  programs  and  the  expanded  AFIT  database,  the  tests 


proved  that  the  new  databcise  performed  as  designed,  at  least  for  the 
test  programs. 

Database  Design  Steps 

This  series  of  steps  was  crucial  in  determining  the  proper  scheme 
to  interface  the  form  utility  with  the  DBMS  and  application  programs. 
The  lack  of  proper  documentation  and  debugged  exanples,  from  Digital 
Equipment  Corporation  to  use  as  guides,  required  additional  design  and 
programming  time  to  gain  the  necessary  knowledge  in  order  to  utilize 
this  most  useful  and  unique  utility.  Once  installed,  the  ability  to 
change  or  add  additional  forms,  without  adding  huge  amounts  of  accon- 
panying  code,  became  a  much  simpler  exercise.  In  a  matter  of  fact, 
utilizing  the  form  manager  frees  the  progranrer  frcm  worrying  hew  to 
both  capture  data  for  the  database  and  write  the  application  program 
within  the  same  program.  Once  the  application  program  is  written,  the 
form  can  be  constructed;  or,  the  program  can  be  written  after  the  form 
is  conpleted.  The  additional  coding  required  to  place  data  into  or 
retrieve  data  from  the  database,  utilizing  a  displayed  form  to  the  (CRT) 
screen,  can  be  included  after  the  application  program  is  structured. 

IMS  Version  1.0  (vhich  was  the  only  version  available  for  use  dur¬ 
ing  the  project)  did  not  support  direct  calls  from  PASCAL,  nor  the 
ability  to  call  frcm  FORTRAN  to  PASCAL.  This  necessitated  initiating 
the  database  session  in  PASCAL  and  calling  the  Driver  program  as  a  sub¬ 
routine.  Also  as  a  consequence,  data  veiriables  needed  by  both  PASCAL 
and  FORTRAN  subroutines  were  passed  back  and  forth  in  order  to  effi¬ 
ciently  utilize  the  interactive  ability  to  communicate  directly  from 
PASCAL  to  TOTAL  (although  this  tends  to  violate  good  software 


prograimiing  by  having  global  variables,  however  few,  running  around) . 
This  technique  was  perfected  after  determining  that  a  change  in  the 
FORTRAN  data  capturing  'WRITE'  and  'OPEN'  statements  was  necessary  to 
keep  fran  losing  data  during  the  passing  of  buffers  written  in  P(SITRAN 
and  read  in  PASCAL  with  subsequent  FORTRAN  'writes'  cxi  the  'read'  file 
(this  is  doomented  in  programs  'TEST.PAS'  and  'TESTl.FCR')  .  Suc- 
cintly,  data  captured  into  a  buffer  (utilizing  IMS  screens)  was  ini¬ 
tially  written  to  a  file  utilizing  a  PCRTRAN  write,  which  tended  to 
drop  the  first  character  in  each  line  since  it  was  used  as  a  carriage 
return  read.  Eliminating  this  quirk  fathered  numerous  test  programs. 
The  method  of  writing  to  the  data  file  was  changed  by  inserting  the 
keyword  "Carriagecontrol  =  'none'"  within  the  'OPEN'  ccritiand  (see  pro¬ 
gram  TESTl.FCR)  to  preclude  this  from  occniring. 

This  series  of  steps  became  the  crucial  exercise  in  determining 
the  manner  in  which  the  different  media  would  interface.  The  DBMS  con 
tains  the  data,  the  FMS  contains  the  forms  through  vhich  the  data  is 
entered,  and  the  application  programs  are  the  means  to  join  the 
screens  with  the  DBMS. 

Enhancing  the  user's  ability  to  quickly  check  data  as  well  as  his 
desire  to  manipulate  it  became  the  next  irportant  factor.  The  ability 
to  utilize  the  EWS  in  conjunction  with  application  programs  became  an 
integral  part  of  the  project.  This  thrust  became  a  challenge  to 
adequately  package  the  FMS  into  the  database  utilities  to  support  the 
expanded  database  providing  a  much  more  efficient  and  user  friendly 
environment  and  do  so  in  order  to  simplify  the  required  application 
programming  code.  This  work  toward  futxare  expanded  database  usage 


uncovered  a  myriad  of  problems  requiring  solutions  in  order  to  effec¬ 
tively  utilize  this  package  with  TOTAL.  On  the  other  hand,  including 
PMS  reduced  the  amount  of  new  and  old  code  required  to  perform  identical 
aK>lications.  Such  enhancement  thus  allcx>ed  writing  more  siirple 
applicatioi  programs  which  utilized  the  more  transportable  MS  form 
modules . 

At  this  point  the  technique  required  to  integrate  the  PASCAL  appli¬ 
cation  program  with  the  MS  written  in  FORTRAN  (which  would  insure  data 
transmission  between  modules)  had  been  accorplished. 

Following  this,  the  next  test  consisted  of  merging  the  two  pre¬ 
vious  results  in  order  to  determine  the  proper  interaction  and  function¬ 
ing  of  the  different  programs: 

1.  The  PASCAL  application  program 

2.  The  FCRTRAN  EMS  Driver 

3.  The  TOTAL  database 

NSTUDENT.PAS  was  selected  from  the  initial  test  programs  for  modifica¬ 
tion  and  testing.  Since  the  previous  testing  had  established  how  to 
acccrplish  data  transfer  fron  PASCAL  to  the  FCHTRAN  Driver  and  back,  the 
program  was  modified  to  further  incorporate  interaction  with  the  TOTAL 
DBMS  and  the  expanded  AFIT  database.  Throughout  this  test  only  small 
changes  were  made  to  insure  continued  progress  without  losing  extensive 
amounts  of  time  due  to  debugging  caused  by  numerous  possible  coding 
errors . 

An  additional  problem  was  discovered  during  the  assignment  of 
variables  from  data  retrieved  out  of  the  database.  Utilizing  the  EWS 
'PUT'  statement,  data  is  placed  on  the  screen  through  the  form  tenplates. 


Even  though  particular  fields  cure  designated  to  display  data  only  (only 
the  application  program  may  enter  data  in  these  fields) ,  it  is  incum¬ 
bent  upon  the  prograitmer  to  pay  particular  attention  to  the  placement 
of  data  since  during  this  operation  data  may  be  displayed  into  any 
field,  even  those  fields  into  vdiich  the  user  may  not  input  data. 

The  resultant  program,  NEVJSTDT.PAS,  called  the  PCRTRAN  Driver, 
TESTNEW.POR.  These  programs  vi^re  modifications  of  the  previous  test 
programs  (see  page  5-13)  with  TOTAL  interfaced  for  the  first  time.  The 
many  small  changes  required  to  achieve  the  ability  to  input  student  data 
into  the  database  mcister  STDT  data-set  and  then  to  retrieve  and  modify 
the  data  quickly  proved  the  test  plan  was  valid.  This  test  was  conpleted 
in  less  than  the  week  that  was  planned.  The  resultant  reduced  amount  of 
code  required  to  achieve  the  test  results,  as  well  as  the  concanitant 
ability  to  rapidly  update  master  data-sets,  was  a  direct  consequence  of 
using  the  IMS  in  conjunction  with  TOTAL  DBMS. 

Continuing  to  build  onto  the  previous  results,  the  NBVSTDT.PAS 
Driver  was  modified  to  begin  the  interactive  session  with  the  beginning 
screens  within  the  library,  and  to  determine  the  social  security  nuitiser 
(key)  of  a  generic  individual.  Modification  in  this  manner  utilized 
existing  code  vdiile  expanding  the  capabilities  of  the  fledgling 
expanded  database  utilities.  This  capability  would  allow  either  student 
or  faculty  data  areas  to  be  directly  accessed  by  later  application  pro¬ 
grams  to  better  serve  the  needs  of  the  frequent  database  user. 

Consequently,  the  Driver,  now  designated  NPERSCW.PAS,  returned  the 


user  request  regarding  either  student  or  faculty  data.  In  actuality, 
vdiat  was  returned  to  the  calling  module  was  the  user  choice  of  the 
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activities  offered  on  the  'FIRSTl'  form  (see  page  5-3) .  By  allowing  the 
module  to  return  this  data  fron  the  FCSRTE?AN  EMS  program,  redefined 
TEST2.FCR,  the  Driver  was  able  to  use  the  data  to  determine  which 
modules  to  route  the  in-use  user  defined  program.  This  use  of  a  variable 
already  used  within  the  FORTRAN  EMS  program  for  use  within  a  case  state¬ 
ment  in  the  new  Driver  program  did  not  increase  the  number  of  variables 
within  the  program,  although  it  did  require  another  global  variable. 

The  trade-offs  in  non-specificity  and  clutter  were  acknowledged  and 
accepted  b>  the  increased  ability  of  the  utility. 

The  use  of  the  returned  variable  'RESP'  was  subsequently  used  with¬ 
in  the  module  'Selectoperation'  to  route  the  program  to  separate  E^  and 
PASCAL  utility  programs  to  accorplish  each  specific  task  and  return  to 
the  calling  module  when  completed.  Although  limited  in  operation,  the 
addition  of  application  programs,  in  the  form  of  modules,  premises  to  be 
a  more  efficient  and  user  friendly  operation  (using  the  EMS  utility) 
than  requiring  the  user  to  know  about  and  call  each  separate  application 
program,  requiring  built-in  code  for  input  or  output  of  data,  which  was 
the  manner  of  operation  vhich  existed  prior  to  tiie  beginning  of  this 
project.  The  PASCAL  Driver  program  is  designed  for  modularity  and  expan¬ 
sion,  necessitating  the  progranmer  code  only  utility  specific  ^plica¬ 
tion  programs  and  little  additional  coding  required  to  connect  to  the 
main  program  Driver. 

Test  Plan 

A  formal  test  plan  to  test  the  validity  of  the  system  design  for 
the  TOTAL  DBMS  Driver  program  has  been  developed.  A  set  of  specific 


tests  for  the  generalized  design  was  developed  using  the  functional 
requirements  found  in  Appendix  M.  A  sample  test  module  is  shown  in 
Figure  V-5.  The  Test  plan  contains  the  functional  requirement,  special 
test  ccises,  expected  results  of  the  test  ccises,  actual  results  of  each 
test  case  and  a  remark  section.  The  ccnplete  test  plan  will  be  deter¬ 
mined  based  upon  the  application  programs  and  the  DBTA  (see  Appendix  N) . 
Throughout  the  coding  and  inplementation  of  the  Driver  program,  test 
procedures  were  conducted  using  the  individuals  who  had  been  interview 
subjects  at  the  beginning  of  this  project.  When  ;>;arranted,  additional 
changes  to  design  were  made  eifter  such  discussions  (such  as  allowing 
the  user  to  exit  the  Driver  program  prior  to  the  ' FIRST  1'  screen, 
before  the  'Signon'  procedure) . 

Test  Procedures 

The  test  plan  presented  was  implemented  using  incremental  testing 
based  on  software  engineering  (24) .  The  test  procedures  used  unit, 
integration,  validation,  and  system  testing  (19:295-305) .  Unit  testing 
ensures  each  module  performs  as  specified.  Integration  testing  ensures 
modules  of  a  program  communicate  correctly  with  each  other.  Validation 
testing  ensures  the  program  meets  the  functional  requirements.  System 
testing  ensures  all  software  in  the  system  performs  correctly  and  meets 
the  functional  requirements. 

Sunnary 

At  this  point  the  main  thrust  of  the  project  was  achieved.  By 


utilizing  the  techniques  for  relating  the  different  means  of  achieving 
this  blend  of  powerful  DBMS,  extremely  user  and  prograittner  friendly 
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rEQUIREMEMT:  1.2  -  Allow  user  to  select  type  of  database  operation. 
TEST  CASE(S)  ; 

1.  No  selection  entered. 

2.  Wrong  type  data  entered. 

3.  EIxit  selected. 

EXPE)CTED  RESPONSE: 

1.  Unless  exit  selected,  user  unable  to  advance  until  proper 
response  made. 

2.  Data  not  acdepted  for  input,  terminal  signals  this  to 
user  in  form  of  bell. 

3.  If  choice  is  exit,  shut  down  database  and  log  off. 

RESULTS: 

CASE  1.  -  PASS; _  FAIL: _  DATE: _ 

CASE  2.  -  PASS: _  FAIL: _  DATE: _ 

CASE  3.  -  PASS;  FAIL:  DATE: 


TESTED  BY: 
REMARKS 


(23: APPENDED  D) 


Figure  V-5.  Sanple  Test  Plan 
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EMS  utility,  and  application  programs,  a  very  powerful  and  more  easily 
maintainable  system  was  created. 

This  chapter  characterized  the  TOTAL  DBMS,  provided  an  overview 
of  the  EMS  utility,  and  presented  the  steps  utilized  in  interfacing  the 
above  with  tl>e  database  schma,  DBMS,  and  prograitming  utilities.  Scxne 
of  the  problems  and  solutions  to  those  problems  are  mentioned  in  an 
effort  to  assist  future  work  on  the  database.  The  coding  and  testing 
described  in  this  chapter  resulted  directly  from  the  design  determined 
utilizing  the  Software  Development  Life  Cycle  described  in  Chapter  1. 
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chapter  6 


VI.  Conclusions  and  Reconmendations 


Introduction 

This  chapter  presents  the  conclusions  and  recomnnendations  derived 
f ran  the  results  achieved  by  this  study.  In  so  doing,  the  Software 
Development  Life  Cycle  continues  to  be  referenced  to  highlight  the  ef¬ 
forts  taken  to  develop  lasting  results. 

Conclusions 

The  initial  part  of  the  project  was  to  enlarge  the  AFIT  database 
to  include  Faculty  data  portions.  This  was  accotplished  utilizing 
various  personal  interviews  and  practicing  a  technique  to  design  an 
entire  database  as  if  one  did  not  already  exist.  The  time  spent  validat¬ 
ing  expected  user's  requests  for  specific  data  items  and  requested 
application  program  data  items  generated  atomic  values  used  to  determine 
the  expanded  database  configuration. 

During  the  development  of  the  Expanded  AFIT  database,  the  expected 
result  was  that  this  would  be  a  multi-user  enviroTment.  This  underlies 
the  Security/ Integrity  concerns  which  must  continue  to  be  shaped  and 
monitored.  Accordingly,  the  database  was  designed  with  these  considera¬ 
tions  in  mind. 

Multiple  I/O  areas  were  defined  in  the  original  design  Data-Base- 
Generation  for  the  purpose  of  making  available  additional  multi-user 
menory  work  space  areas.  Multiple  taskings  of  data-sets  are  not  allowed 
under  TOTAL  unless  separate  work  areas  (scratch-pad- like)  containing 
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additional  copies  of  the  data-sets  are  available.  Accordingly,  the 
arrangement  of  the  data-sets  into  groupings  v^iich  would  assist  this 
multiple-user  environment  was  acknowledged  and  inplemsnted.  Those  data¬ 
sets  believed  to  be  most  helpful  within  the  anticipated  user  environ¬ 
ment  had  additional  work-space-arecis  designated  to  allow  distinct  user 
actions. 

Working  through  the  Requirements  Analysis  and  Specification  phase, 
the  database  schema  was  designed  to  accommodate  the  desired  and  expected 
taskings  of  the  user.  Testing  the  code  defined  by  the  data  definition 
language  required  that  it  be  able  to  store  the  input  data  and  return 
data  via  links  determined  within  application  programs  acting  through 
this  DDL. 

The  resultant  database  now  contains  the  required  data  elements 
desired  and  requested  to  perform  the  myriad  of  additional  tasks  antici¬ 
pated  for  it  to  acccrnrnodate .  The  use  of  the  Form  Management  System  as 
an  enhanced  data  display  utility  ansvers  the  need  for  data  presentation 
in  user  understood  and  easily  repeatable  format.  In  a  conscious  effort 
to  assist  the  user  in  entering  and  checking  data,  scroll  areas  were  not 
used.  Thus,  when  entering  many  items  of  data  onto  a  predefined,  data¬ 
base  provided,  EMS  produced  form,  the  entire  form  may  be  easily  seen  and 
checked  on  one  screen  utilizing  no  scrolling  to  see  all  tne  data  con¬ 
tained  on  the  form  prior  to  entering  the  data  into  the  database. 

The  use  of  the  menu  format  to  page  through  the  available  database 
utilities  is  considered  as  the  best  means  of  user-friendly  prcnpting  and 
'directing  traffic'  without  excessive  verbiage.  The  current  menu 
listings  enconpass  student  and  faculty  personal  data,  book  and 
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scheduling  information  and  a  separate  section  for  utilities  (Student 
Graduate  Credit  Record,  Ed  Plan,  etc.) .  The  menu  utility  also  permits 
the  user  a  built  in  ability  to  back  up,  within  the  menu  itself,  if 
desired  in  planned  application  programs. 

The  most  inportant  features  inplanented  for  use  by  this  expanded 
database  is  the  inherent  ability  for  easy  expansion  and  an  equally  easy 
means  allowing  the  user  to  find  quickly  the  type  of  operation  he  desires 
to  perform.  Since  the  Driver  program  allows  the  user  to  determine  the 
type  of  utility  he  desires  to  select  before  iiiplementing  any  database 
usage,  future  database  utilities  can  be  written  and  added  with  a  minimum 
of  Driver  changes. 

The  menu  system  set-up  within  the  called  form  subroutine  and 
utilized  throughout  the  database  utilities  encourages  the  ability  to 
build  in  utility  and  user  specific  security  for  the  access  of  specific 
utilities  or  data  items  within  the  database.  As  the  number  of  users  and 
the  type  of  data  utility  application  programs  expand,  the  security  con¬ 
cern  will  no  doubt  also  increase.  Thus,  the  database  and  its  surround¬ 
ing  form  utility  system  will  be  able  to  keep  pace.  Sane  of  the  problems 
and  solutions  to  those  problems  encountered  during  the  course  of  this 
project  were  mentioned  in  the  course  of  the  documentation  in  an  effort 
to  assist  future  work  on  the  database  or  its  utilities. 

Recommendations 

The  Software  Development  Life  Cycle  approach  follCMsd  for  the 
development  of  the  AFIT  Database  includes  provisions  for  additional 
coded,  tested,  and  integrated  application  programs.  Future  work  to 
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ccnplete  the  aH>lication  programs  proposed  during  this  project  and  to 
make  use  of  the  newly  included  atomic  data  items  added  for  j;ist  such  new 
programs  (see  Appendix  H)  should  be  mdertaken  to  obtain  the  expected 
utility  from  this  project.  Work  yet  remains  to  conplete  conversion  of 
the  original  database  application  programs  to  this  database  system  and 
to  inplement  additional  ones.  The  means  to  input  and  display  all  applic¬ 
able  data  is  in  place.  The  entire  Form  Library  is  in  place  with  anple 
screens  to  enconpass  those  original  and  expanded  requirements.  The 
ability  to  access,  add  and  modify  student  and  faculty  personal  history 
data  is  fully  operational.  The  conversion  and  writing  of  those  applica¬ 
tions  regarding  student  ed  plan  manipulations  and  other  utilities  cure 
still  pending.  Student  database  projects  conpleted  within  database 
classes  could  be  utilized  to  add  those  applicaticxi  utilities  to  the  data 
base  in  a  more  timely  manner. 

Another  recciiinendation  is  that  the  maxlxrum  size  DBMCX)  permissable 
be  determined  prior  to  cotpleting  the  database  for  multi-user  operation, 
as  discussed  in  Chester  4.  As  previously  discussed,  only  a  few  of  the 
multiple  work-space  areas  need  be  deleted  (prelimineuy  work  indicated 
that  any  twj  of  the  variable  work-space  areas  would  suffice) .  It  was 
decided  not  to  nrake  this  change  due  to  limited  time  requirements  for 
needed  conprehensive  testing  procedures.  Those  data-sets  determined 
during  this  project  to  require  multiple  work-space  areas  and  were 
originally  specified  in  the  DBG  are  listed  in  ;ppendix  K. 

As  much  as  this  project  extolled  the  utility  of  the  FMS  special¬ 
ized  display  technique,  another  recomendation  is  that  AFIT  obtain  the 


documentatioi  for  the  upgraded  versions  of  EMS.  This  project  utilized 
Version  1.0  vdiich  was  limited  from  utilizing  embedded  PASCAL  EMS  calls 
which  Version  2.0  supports.  In  this  manner  additional  use  can  be  made 
of  the  utility  by  directly  embedding  the  EMS  calls  within  the  applica¬ 
tion  programs  and  enhancing  the  programmer *s  ability  allowing  the 
prograititier  to  write  both  the  program  and  call  forms  \;ising  PASCAL  alone. 

The  implementation  of  the  working  DBA  (as  discussed  in  i^pendix 
N) ,  should  portend  few  if  any  problans.  Acknowledging  that  obtaining 
additional  personnel  to  care  for  the  AFIT/ENG  database  may  not  be 
possible,  this  project  emphasized  that  additional  personnel  need  not  be 
required  and  these  tasks  may  be  absorbed  as  additional  responsibilities. 
Both  positions  characterized  by  the  DBMS  and  DBTA  presently  have 
individuals  functioning  in  their  respective  capacities.  The  initial 
question  is  vdjether  the  third  individual  will  be  assigned,  based  on  the 
project  reconmendation.  However  this  is  acccmplished,  this  position 
should  be  looked  into  to  insure  adequate  and  conplete  data  records 
ccntinue  to  be  kept. 

The  performance  chcuracteristics  of  the  database  should  also  be 
investigated  in  an  effort  to  improve  performance  and  obtain  the  best 
operation  given  the  aveiilable  means  (23  and  25) .  Additional  work  to 
provide  this  information  should  be  done  within  the  framework  of  an  addi¬ 
tional  thesis  effort.  Work  to  cotplebe  this  network  database  to  obtain 
a  true  multi-user  network  of  terminals  utilizing  the  TOTAL  multi-user 
approach  should  also  invite  further  study. 
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Appendix  A 

Data  Ouestionnaire  to  Ccttplete  Develqpirent  and  Inplement 

AFIT/EUG  Database 

The  purpose  of  this  questionnaire  is  to  gather  data  to  assist  in 
cotrpleting  develcptient  and  irtplement  the  AFIT/ENG  Database  management 
system  utilizing  TOTAL.  Proposed  inplementations  encatpass  the  Gradu¬ 
ate  Student  Credit  Record  and  the  Faculty  entries.  This  portion  of 
the  database  will  exist  on  the  Digital  Lab  VAX  11/780  as  does  the  cur¬ 
rently  running  Student  portion  of  the  AFIT  Database.  Your  answers  will 
provide  the  input  for  the  system  conposition  and  determine  hew  well  it 
may  cissist  your  office  and  work. 

This  interview  form  is  designed  to  be  used  in  conjunction  with 
persCTial  interviews  of  those  selected  individuals  nost  likely  to  have 
direct  input  into  the  overall  design  and  implementation  of  the  AFIT/ 
EKG  Database.  It  is  understood  that  this  interview  form  is  not  in  and 
of  itself  conplete  and  all  inclusive. 

Ihe  accuracy  and  caipleteness  with  which  you  respond  to  the  fol¬ 
lowing  and  any  follow-on  questions  which  may  arise  will  determine  the 
outcome  and  content  of  this  portion  of  the  AFIT/ENG  DataBase. 

1.  What  kind  of  data  is  required  by  your  organization?  (Can  you 
categorize  this  data  within  such  areas  as  Faculty,  Student, 
Graduate  Student  Credit  Record,  organization,  etc.?) 

2.  Can  you  f\irther  define  each  major  area  and  discuss  functions 
and  procedures  vhich  relate  to  and  among  each  other? 

3.  What  attributes  do  you  require  for  each  piece  of  data? 

4.  What  are  the  attribute  names,  values  and  sizes  for  each  piece 
of  data? 


5. 


Briefly  e^lain  any  relationships  among  your  data. 

6.  Briefly  explain  any  relaticaiships  within  each  data. 

7.  Are  there  any  queries  you  might  routinely  search  for  in  the 
Database? 

8.  What  is  the  format  in  which  queries  should  appeau:? 

9.  How  do  you  envisicxi  the  output  format  should  appear? 

10.  Hew  user  friendly  do  ycu  envision  this  portion  of  the  AFIT 
Database?  (i.e.,  how  conputer  query  literate  will  be  those 
users  v4io  utilize  this  portion  of  the  Database?) 

This  work  is  being  conducted  by  MftJ  Mike  Pangman  in  the  pursuit  of 

satisfying  requirements  to  dbtain  a  Master  of  Science  degree.  Thank  you 

for  your  assistance. 


Ag^jendix  B 

Interview  Subject  Responses 


The  following  lists  the  interview  respcxises  conducted  to  antici¬ 
pate  future  and  present  user  database  requirements.  The  listing  is  sub¬ 
divided  by  subject  areas  and  ccxitains  those  requirements  the  inter¬ 
viewees  requested  to  have  incorporated  into  the  expanded  AFIT  database. 
Duplications  are  preserved  to  display  the  full  interview  responses. 

STUDENT 


1.  Presently,  updating  is  tedious: 

-  Can  only  change  one  field  during  one  (^ration,  would 
prefer  doing  all  required  changes  on  a  record  during 
one  operation; 

-  Presently,  vdien  searching  for  a  name,  the  search 
returns  every  name  prior  to  presenting  a  listing  of  the 
names  viMch  match  the  request.  At  this  point  the  num¬ 
ber  from  the  list  correspcxiding  to  the  desired  name  is 
chosen  to  obtain  the  listing.  However,  if  the  incor¬ 
rect  name  is  chosen,  the  process  must  be  repeated 
rather  than  have  the  previous  sort  retained  and  avail¬ 
able  for  a  second  try. 

2.  Add  the  Faculty  Advisor  to  the  database. 

3.  List  the  Instructors  and  courses  each  teaches  or  is  scheduled 
to  teach: 

-  Be  able  to  query  instructor  schedule  for  future 
courses; 

-  Query  for  a  particular  instructor  or  course  in  a 
particuleu:  qucurter. 

4.  Wants  to  PERSONALLY  get  listing  of  number  of  students  enrolled 
for  each  course  for  future,  without  requiring  DBTA  to  do  it 
for  him; 

-  Would  like  to  get  notice  printed  out  for  each  indivi¬ 
dual  signed-up  for  a  course  \dien  it  will  not  be 
offered  -  like  STUDENT-SECTION  DESIGNATION-ADVISOR, 

5.  Currently  gets  a  printout  containing  Student/quarter/courses/ 
hours/grades;  would  like  abbreviated  version  also. 

6.  Would  like  Independent  Study  (Thesis/Doctorate)  course  to 
represent  exactly  how  many  hours  are  scheduled  for  each 


PI  ■rp  ,  I  1 ,  ■  , 


quarter  -  do  it  for  1-12  hours;  change  default  from  current 
4  hours  to  acccmmodate  this. 

ADVISCR  -  ^ 

1.  Revise  the  database  to  encorporate  a  management  tool  vdiich  v' 

can  determine  GPAs  and  assist  in  filling  out  Graduate  Record 

data  for  requisite  forms.  This  would  be  most  helpful  -  espe¬ 
cially  since  this  is  needed  quickly  just  prior  to  Graduation: 

-  calculate  GPA  for  48  Graduate  Credit  hours; 

-  determine  remaining  courses  and  calculate  their  GPA; 

-  calculate  a  GPA  achieved  by  all  the  Graduate  Courses 
(minus  all  the  undergraduate  courses) ; 

-  calculate  GPA  consisting  of  all  courses  taken. 

2.  Be  able  to  supply  data  for  AFIT  form  78/79  (?) . 

3.  (A  few  instructors  were  not  interested  in  personally  inputing 

or  retrieving  this  data,  as  long  as  DBTA  or  secretary  pro-  ^ 

vided  this  support.)  •; 

4.  Course  Scheduling  should  be  projected  out  to  18  months  to  take 

advantage  of  building  Student  Ed  Plans.  Since  Advisor  is  re¬ 
sponsible  for  maintaining  current  Ed  Plan  of  his  students,  he  " 

should  be  able  to  make  updates  to  the  database,  v^le  others,  ' 

who  do  not  have  a  need,  are  kept  out.  An  anticipated  reduc-  ■ 

tion  of  paper  flow  and  differing  versions  of  Ed  Plans  between  I;-  --; 

the  Department  and  AFIT  Administration  are  expected  with  this 

database  expansion.  Database  could  also  be  used  as  a  means  of 

recording  coordination  of  Ed  Plans  or  otlier  items  made  between  ’  ^ 

individuals.  The  advisor  could  then  give  each  student  a  copy 

of  his  Ed  Plan.  (EMPHASIZED  AGAIN)  This  would  assist  the 

class  advisor,  individual  student  advisor  and  thesis  advisor 

more  quickly  than  present  system. 

5 .  System  should  also  handle  inconing  students  data  prior  to  their 

actual  arrival  vdiich  would  necessitate  being  able  to  insert  ; 

partial  data. 

6.  Enter  end-of -course  grades  on  line  by  instructor  to  flesh  out  .  .j 

Ed  Plan;  Registrar  would  still  receive  a  copy  of  grades  which  ' 

could  reduce  the  amount  of  hardccpies  shuttled  back  and  forth. 

Electronic  signature  to  verify  this  type  of  data  (and  data 

transfer)  is  a  future  possibility.  . ! 

-  Seaurity  -  This  would  be  of  great  concern  for  an  on-  ..  - 

line  Ed  Plan. 
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-  Entering  individual  data  requires  Social  Security  Number 
(SSN)  or  a  sort  routine  as  exists  to  choose  among  students 
by  name  thereby  bypassing  the  security  the  Social  Security 
Number  (SSN)  provides. 

-  Grades  in  database  also  create  a  security  access  problem. 

-  Update  Ed  Plan  using  separate  grades  file  either  autoratic- 
ally  or  have  it  done  separately  vhen  updating  Ed  Plan. 

MANfiGSyiEMT  TOOLS 

GRADUATE  CREDIT  RECORD 

1.  Used  as  official  document  for  approval  or  disapproval  of  all 
graduations. 

2.  Ability  to  calculate  GPA's  —  presently  it  must  be  accom¬ 
plished  by  hand  prior  to  Standards  Committee  meeting  and 
approving  graduates  for  graduation. 

3.  Need  database  to  split  course  hours  by  number  of  design  and 
theory  hours  AIJD  have  this  break-out  listed  properly  onto  Grad¬ 
uate  pc^ierwork  vhich  requires  it  broken  out  by  design  and  the¬ 
ory  hours.  (One  4-hour  coiurse  broken  into  2  hours  credit 

to  each  area.) 

^  PLftN 

1.  Access  available  on  individual  terminals. 

2 .  ^  plan  output  format  should  confirm  to  AFIT  Form  29  Ed  Plan. 
Also,  a  routine  to  check  a  tentative  Ed  Plan  to  determine  whe¬ 
ther  the  data  contained  within  it  is  valid.  Those  which  do 
not  match  existing  requirements  have  a  'flag'  set  so  that  er¬ 
rors  may  be  displayed  cifter  the  check  has  been  made.  (e.g.  a 
'4'  level  course  could  have  separate  'validated'  or  'not  vali¬ 
dated'  items) 

3.  A  routine  to  determine  vhether  listed  courses  in  Ed  Plan  are  in 
fact  offered  for  that  pcurticular  quarter. 

4.  A  routine  to  DELETTE  entire  Ed  Plan  vA^en  required  rather  than 
having  to  delete  each  item  (course,  quarter,  etc.),  including 
student  name  and  Social  Security  Number  (SSN)  -  the  inability 
of  the  present  database  to  do  this  adds  time  in  order  to 
eliminate  data  piecemeal . 


-  Would  like  to  obtain,  on  a  calender  or  academic  year 
basis  (and  probably  by  quarter  as  well) ,  the  teaching 
load  sum  by  individual 

-  Would  also  like  to  obtain  Professional  Etevelopment 
Ouarter  listing;  list  should  be  broken  out  by 
quarter  (this  will  alert  him  as  to  vdiy  his  load  is 
low,  or  vAiich  quarter  his  instructor  is  'free') 

(*)  Graduate  Record  Data 

-  Verify  Degree  Requirements 

*  check  sequence  entries  (know  which  courses  make 
up  sequences) 

*  Proper  #  math  credits  not  in  sequences  and  not 
programming  courses  (would  need  to  list 
individual  courses  or  code  math  prograitming 
courses) 

*  Determine  sequences:  at  least  7  hours/sequences 
but  total  of  2  sequences  must  equal  minimum  of 
17  hours 

*  Other  Graduate  level  courses  -  minimum  total 
equals  48  hours  (check  to  insure  CMLY  Graduate 
courses  up  to  here  &  NO  RESTRICTED  COURSES 
<Restricted  courses  from  48  hour  total  for 
Graduate  Credit:  EE  545,  EE  560,  EE  562, 

EE  572,  EE  573,  any  Systems  Management  (to 
include  Operational  Sciences  also)  and  CT 
courses >) 
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At  the  point  v/here  the  teaching  load  is  deter¬ 
mined,  he  wants  to  be  able  to  determine  and 


input  to  the  Instructor  Load  Determining  Func¬ 
tion  the  number  of  sections,  based  on  the 
known  number  of  students  signed  up  for  the 
course  -  does  not  want  to  rely  on  a  magic  fig¬ 
ure  to  split  a  cou-se  into  subsequent  sub¬ 
classes  (15  is  the  usual  figure  for  dividing 
labs)  —  J±  Instructors  share  a  course,  deter¬ 
mine  load  and  divide  the  total  equally  amcng 
instructors  (2  or  more) 

For  lecture  portion  of  the  course,  use  30  as 
a  default  figure  -  but  still  have  option  to 
break  up  a  smaller  class  into  smaller  sections 
(be  able  to  change  default  option?) 

Load  also  includes  number  of  theses  instruc¬ 
tor  handles  -  computed  as  18  contact  hours  per 
coipleted  thesis  by  ccrpletion  date  -  would 
like  to  query  on  academic  (fiscal)  year 
(FALL  -  SUMMER) ,  and  calender  year  (VJINTER  - 
FALL) . 

Load  also  includes  any  short  term  teaching 
hours  -  this  is  ccnputed  on  the  ACTUAL  NUMBER 
of  Hours  person  teaches 

Interested  in  obtaining  the  total  load  time 
and  not  the  breaikout  by  lecture  and  lab 


(*)  student  Ed  Plan 


-  List  name  &  quarter  &  course  when  scheduled 
ccurse  not  offered 

-  Able  to  flag  errors  cai  Ed  Plan 

-  Accept  grades 

-  Flag  prerequuisites  -  need  to  know  what  they  are; 
flag  if  not  met  or  waived. 

(*)  Determine  Teaching  Loads  -  would  like  to  get  individual 
or  entire  list  of  faculty  teaching  loads  (MANAGEMENT  TOOLS) 

-  Teaching  Loads  defined  as: 

*  If  a  lecture  course  -  multiply  #  lecture 
hours  by  11 

*  If  a  lab  course,  multiply  the  Lab  section 
time  by  11  (#  of  actual  hours  of  time  spent 
a  veek  in  lab) 

*  EXAMPLE:  4  Hours  total  course  broken  out  by 
3  hours  lecture,  and  3  hours  lab  (called 
direct  teaching  hours) ;  3  lecture  hours  x 

11 <■  33  +  3  lab  hours  X  11  =  33  also,  for  a 
total  of  66.  (normal  credit  hours  are  3  for 
lecture  and  1  for  lab,  but  actual  #  of  lab 
hours  is  3) 

*  If  two  lab  sections,  then  the  number  for  that 
is  counted  twice  (total  for  2  labs  would  then 


beccrte  99) 


-all  students  within  each  class 


-  faculty  advisors 

-  thesis  advisors 

-  thesis  data  -  SHJDENT/ADVISGR/BOX  #/CLASS/TEESIS 
TOPIC/COMMTITEE  MEMBERS 

4.  Internal  Course  Data  -  STODEM'/HQMe  PHCNE  #,  BOX  #,  PROOEXJT 
ASSIGNED 

5.  (*)  Army  Students  class  data  -  arranged  so  they  are  counted 
in  Database 

-  arranged  by  Fiscal  &  Acadsnic  year 

-  arranged  by  clciss  designation 

-  determine  clciss  leader  &  faculty  advisor 

6.  (*)  Instrxactors  linked  to  courses  (past,  present,  future) 

-  Under  Course  -  TITLE,  #  CREDIT  HOURS,  TEXT  USED, 
INSTRUCTOR,  C^JARTER 

-  Determines  projected  enrollments 

-  Used  to  determine  whether  a  class  will  be  taught  or  not 
based  on  number  of  students  signed  up  through  Ed  Plans; 
this  could  be  projected  as  early  as  first  quarter  after 
completing  Ed  Plans 

-  Useful  for  notifying  students  if  a  course  is  to  be  can¬ 
celled  -  to  alert  them  and  advisor  to  revise  Ed  Plans 

-  Useful  for  determining  number  of  books  to  be  ordered 
(unsure  as  to  who  really  determines  the  number  of 
ordered  texts) 

-  To  assist  instructor  book  ordering  and  rocm  scheduling 
Subject,  Number  of  Students  Scheduled  Per  Quarter. 
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Appendix  D 

Prioritized  Listing  of  Proposed  New  Database  Requirements 

The  subject  areas  listed  in  this  Appendix  were  extracted  from  the 
interviews  conducted  to  achieve  responds  to  the  areas  required  to  be 
addressed  by  the  results  of  this  project.  Each  area  has  a  designation  as 
to  the  priority  for  its  underteiking.  This  designation  is  indicated  by 
asterisks  next  to  the  numbered  subject  cirea  -  one  asterick  is  for  first 
priority,  two  asterisks  are  for  second  priority,  and  three  asterisks  are 
for  third  priority. 

1.  (*)  Thesis  Course  -  revise  default  credit  for  thesis  course 
from  4  to  any  number  of  hours 

2.  (*)  Inprove  menus  in  databeise 

-  more  user  friendliness 

-  provide  more  help  to  navigate  through  system 

-  be  able  to  use  Icwer  case  letters 

-  correct  present  menu 

*  'L'  or  'S'  is  asked  for  and  proper  response  not 
received  since  program  is  looking  for  a  numerical 
response 

3.  (*)  Additional  Links; 

Faculty  Advisor  - >students 

Faculty  Advisor  - >thesis  students 

student  - >faculty  advisor 

student  - > thesis  advisor 

Link  to  class: 
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{Course  Data;  COURSE  MBffiER,  CREDIT  HOURS,  LBCHRS,  lABHRS 

DESCRIPTICN,  OUTLINE,  SIZEIMT} 

Professional  development  quarter;  FSSN,  QUARTER 

{Rooms;  ROOM,  BU3G,  NUMBER  ALLOWED 

Schedule;  DATE,  TIME,  ROOM,  COURSE  NUMBER} 

Ed  Plan;  COURSE,  SEQUENCE,  PRERBQ,  SSSN,  SECTICN,  SHADES, 

Thesis  Carmittee  Members;  FSSN,  Thesis  Ntmber,  SSSN 

Sequence ;  Sequence  name 

{Prereq;}  COURSE  NUMBER,  PRERBQ,  NUMBER 

{Offerings : }  COURSE  NUMBER.  QUARTER 

{Dates;}  QUARTER.  DATE 

Degree  Req:  THESIS.  MATH.  SEQUENCE,  GRADES,  TITLE 
RestrictedjZourses;  COURSE  NUMBER,  TITLE 
{TITLE:  COURSE  NUMBER.  TITLE} 


FSSN 


i 


l>k 
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^^^pendix  C 
Attribute  Listing 

This  listing  conpares  the  records  and  attributes  listed  in  Allred's 
thesis  (2:55)  with  those  atonic  data  values  initially  determined  after 
the  interview  process  was  conpleted.  Those  items  listed  in  {  }  are  the 
items  envisioned  for  the  AFIT  database  using  the  Relational  scheme  with 
the  keys  for  each  record  underlined.  As  depicted,  a  number  of  keys  are 
useful  in  the  TOTAL  network  model.  This  information  is  strictly  for 
ccnparison  between  the  original  relational  design  scheme  and  the  estab¬ 
lished  AFIT  database  using  a  network  DBMS. 

Faculty  Professicnal  Data  { (Ccnriittees) :  FSSl'J,  Ccnirdttee} 

(Army)  {Students:  SSSN,  Name,  rank,  PAFSC,  DAFSC,  Ed  Code,  DOR,  DOC, 

DOB,  POB,  Phone,  Duty  Phone,  Address,  Elnergency 
Address,  Spouse,  Spouse  Date  of  Birth,  Number  of 
Depend^ ts.  Service,  Race,  Sex,  Religion,  Aero 
Rating,  Losing  Corrmand,  Military  Spouse,  Years  of 
Service,  Last  Organization,  Position  Title,  Dura¬ 
tion},  Graduated  AFIT  (Y/N)? 

Class;  STUDENT  NAME,  SSN,  BOX  #,  PHCNE  #,  CLASS  LEADER,  FACULTY  ADVISC«, 
THESIS  ADVISOR 

{Thesis  Data:  THESIS  NUMBER,  TITLE,  SPONSOR,  LOCATIOSI,  CLASS IFICATIOJ } , 

FSSN  (ADVISOR) ,  THESIS  COMMITTEE  ME2-1BERS 

Faculty  Advisor:  FSSN,  STUDENT  NAME,  SSSN 

Thesis  Advisor;  FSSN,  STUDENT  NAME,  SSSN,  THESIS  # 

Class  Leader;  SSSN,  CLASS 

Instructor  statistics:  FSSN,  COURSE  NWBER,  QUARTER,  SSSN,  GRADE, 

TITLE,  TEXT  USED 

{Grades;  SSSN,  CQUPvSE  NUMBER,  QUARTER,  GRADE},  COURSE  DATA 

Teaching  Load:  FSSN,  DEPT,  THESIS  NUMBER,  COURSE  DATA,  PROFESSICKAL 
DEVELOPMENT  Quarter. 
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4. 


-  Total  number  Students  in  each  Class  given  quarter,  yeeur, 
section. 

CLASS  GROUP  LISTINGS  -  like  CST84J.  Associate  these  groups 
by  Fiscal  Year  with  the  number  of  students  in  each  class,  the 
class  leader  of  each  group,  and  the  faculty  advisor  for  that 
class.  Add  Army  classes  to  database  to  allow  integration  with 
other  students'  Ed  Plans  to  aissist  instructor  in  projecting 
class  sizes,  books,  projects,  etc.,  better. 

5.  Link  all  the  individuals  within  a  class,  faculty  advisor  for 
each  student,  and  each  student's  thesis  advisor. 

Faculty  Advisor  - >students 

Faculty  Advisor  - >thesis  students 

student - >faculty  advisor 

student - >thesis  advisor 

6.  Link  current  courses  and  peist  courses  taught  with  final  grades 
for  each  student  for  those  courses. 

7.  Assist  instructor  book  ordering  and  roan  scheduling  — 

Subject,  Number  of  students  scheduled  per  quarter. 

8.  Display  student  box  number,  phone  nvonber,  advisor,  class 
designation. 

9.  Keep  track  of  student  already  graduated  to  provide  data  for 
forwarding  materials  or  to  get  hold  of  him  if  needed  -  for 
security  clearances. 

10.  As  it  stands  now,  only  very  few  individuals  have  access. 
Therefore,  'users'  do  not  know  vdiat  is  on  line  and  what  they 
can  have  access  to. 

11.  Need  application  programs  -  detennine  the  highest  need,  even 
if  it  is  already  there,  and  get  those  operational  and 
accessible. 

SECURITY 

1.  Faculty  advisor  should  be  able  to  update  student  Ed  Plans  ajid 
students  should  be  able  to  call  up  their  classes,  Ed  Plans,  and 
grades. 

2.  Database  is  only  cis  good  as  the  data  entered  into  it. 

3.  From  a  query  viewpoint,  should  be  able  to  get  data  from  term¬ 
inal  in  office;  to  change  data,  should  have  to  go  to  find 
administrator  to  get  approval. 

4.  Security  is  of  paramount  caicem. 
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-  NAME,  COMPANY,  ADDRESS,  INTEREST  IDENTIFIERS  IDENTIFIED 
BY  USER,  DATE  OF  EXPIRATION  OF  HIS  TERM  OJ  A  CX3MMITTEE, 
DATE  DATA  ENTERED  C»  MODIFIED,  MISC.,  RESPONSE  FIELD, 
FIELD  TELLING  IF  DATA  HAS  BEEN  SENT. 

3.  Cataloging  invited  attendees  for  a  conference  or  workshop. 

4.  Cataloging  authors  viio  submit  papers  or  abstracts  and  the 
p^)ers  written  (title,  date  submitted,  reviewed,  published, 
yet  published,  refere^  or  non-refereed  journal) . 

5.  Keep  track  of  any  consulting  done  (name  of  oirganization  and 
contact  at  organization;  and  how  correspondence  was  acccm- 
plished-by  telephone,  letter,  or  how). 

6.  Meetings  attended,  talks/briefings  (vAiere  given,  title,  date 
given) . 

7.  Resecirch  Proposals  written  and  submitted: 

-  title,  date  submitted,  results  of  proposals,  members 
of  proposal,  subject,  amount  of  money  requested. 

8.  Acquisition  of  Computer  Equipment  -  AFIT  ACD;  maintaining  lab 
equipment  requests  -  cost,  submitting  requests. 

9.  Everything  listed  relational  within  a  major  area  (ex., ’Deter¬ 
mine  students  in  GCS-84D  taking  course  viicm  instructor  has  not 
yet  seen) . 

OTHER/REQUIRED  KINDS  OF  DATA 


Determine: 

1.  Number  of  students  in  a  given  course  in  a  given  quarter. 

2.  Information  on  each  Student's  Ed  Plan 

-  Form  29; 

-  Form  89; 

-  Form  78. 

3 .  Format  of  information: 

-  Instructor,  queirter.  Year,  Course,  Section  number; 

-  Student  Identification,  Class,  quarter.  Year,  Section 
nunber; 


THESIS  H’JFO  -  Student,  thesis  number,  title; 


-•  (X)tain  Professional  Develcpnent  Quarter  listing;  this 
should  be  broken  out  by  quarter  (this  will  alert  user 
cis  to  why  individual  instructor  load  is  low,  or  vdiich 
quarter  instructor  is  'free'). 

-  Need  to  catalog  faculty  publications  and  instructor 
ccxisulting. 

-  Tcp  priority  should  be  to  get  Student  Database  upgraded; 
this  will  off-load  the  faculty  work  load  and  be  more 
beneficial  than  having  a  Faculty  database. 

-  Wcxild  like  to  know  v±io  is  projected  to  teach  courses  as 
far  in  advance  as  possible  (see  page  2) .  Under  the 
course  —  should  have  —  title,  no.  of  credit  hours, 
text,  instructor,  quarter  matched  up  wi^  the  instruc¬ 
tor,  and  double  ch^k  with  all  students'  Ed  Plan  to 
insure  no  duplicatioi  of  students  within  coirses .  At 
leeist  know  what  the  enrollment  for  a  course  is. 

-  Room  usage  could  be  useful  —  using  the  big  chart  ENA 
has  in  cases  where  clciss  gets  rescheduled.  Required 
information;  number  of  students  room  can  hold,  hour  each 
room  is  used.  Scheduling  conflicts  become  a  problem 
vdien  instructor  has  to  teach  2-3  sections  of  same  class 
vAien  each  sectiai  has  uneven  number  of  students  in  them. 
The  need  to  know  the  nimiber  of  students  in  each  course  is 
imperative. 

-  Instructor  wanted  to  know  if  the  current  system  is  able 
to  project  enrollments  —  that  is,  a  teacher  should  be 
able  to  query  the  database  and  find  how  many  students 
are  enrolled  for  a  particular  course.  This  assists  the 
instructor  in  ordering  the  number  of  texts  needed  for 
his  class.  Orders  for  books  are  submitted  2-3  months 
in  advance.  Instructor  determines  the  book  used  with  a 
course  and  the  academic  department  provides  a  catalog 
number  that  corresponds  to  the  ordered  book.  (Perhaps 
seme  record  between  the  name  of  the  text  and  the  number 
the  department  gives  it  should  be  recorded?) 

PROFESSIONAL  =  FACULTY 

The  databcise  should  keep  track  of: 

1.  Professional  duties  (like  chairman  of  an  IEEE  cenmittee) . 


2.  Any  mailing  list  an  individual  in  this  situation  has  responsi¬ 
bility  for  -  Attributes  could  resemble  this: 


Teaching  Loads  defined  as: 

*  If  a  lecture  course  -  multiply  number  of  hours  by  11. 

*  If  a  lab  course,  multiply  the  Lab  section  hours  by 
11  (nuntjer  of  actual  hours  of  time  spent  a  week 

in  lab) . 

*  EXAMPLE:  4  hour  course  broken  out  as  3  hours  lec¬ 
ture  and  3  hours  lab  (called  'direct  teaching 
hours ' ) ;  3  lecture  hours  X  11  =  33  plus  3  lab 
hours  X  11  =  33  also,  for  a  total  of  66.  (normal 
credit  hours  are  3  for  lecture  and  1  for  lab,  but 
actual  nunber  of  lab  hours  is  3) . 

*  If  there  are  two  lab  sections,  then  the  total  for 
one  is  counted  twice  (total  for  2  labs  would  then 
become  99) . 

*  Must  reserve  ability  to  determine  and  input  to  the 
Instructor  Load  Determining  Function  the  number  of 
sections,  based  cn  the  kncwn  number  of  students 
signed  up  for  the  course  -  does  not  want  to  rely  on 
a  magic  figure  to  split  a  course  into  subsequent 
sub-clcisses  (15  is  the  usual  figure  for  dividing 
labs)  —  If  Instructors  share  a  course,  determine 
load  and  divide  the  total  equaTly  among  instructors 
(2  or  more)  ***  Mi^t  consider  having  the  program 
determine  ’the  number  of  sections  based  an  15  per 
section  and  the  nuirber  of  students  signed  up,  but 
prior  to  conputing,  ask  if  the  user  concurs  with  the 
confuted  number  of  sections  to  be  used  to  determine 
the  instructor  load  data  -  if  not,  user  determines 
number  of  sections  on  vhich  to  ccrrpute  data. 

*  For  lecture  portion  of  the  course,  use  30  students 
per  class  as  a  default  figure  -  but  still  have  option 
to  change  default  option. 

*  Load  also  includes  number  of  theses  instructor  han¬ 
dles  -  conputed  as  18  contact  hours  per  completed 
thesis  by  conpletion  date  -  would  like  to  determine 
this  data  by  academic  (fiscal)  year  -  (FALL  - 
SUMMER) ,  cis  well  as  by  calender  year  (WINTER  -  FALL) 

*  Load  also  Includes  any  short  term  teaching  hours  - 
this  is  conputed  on  the  ACTUAL  NUMBER  OF  HOURS 
person  teaches,  not  the  course  credit  assigned. 

Obtain  on  calendau:  or  academic  year  laasis  (and  probably  by 
quarter  as  well)  the  teaching  load  sum  by  individual. 


(student  grade  data  could  be  kept  within  the  database  under 
this  circuinstance) . 

7.  Other  instructors  want  individual  access  to  data  fron  tenninals 
within  their  offices  -  highly  interactive,  yet  protected 
(SBCURTIY)  . 

8.  Able  to  query  and  print-cut  from  the  Database  vAiich  courses 
students  have  scheduled  for  any  quarter. 

9.  Would  like  to  know  students  signed  up  for  a  future  course: 

-  Used  to  determine  vrfiether  a  class  will  be  taught  based 
on  number  of  students  signed  up  through  their  Ed  Plans; 
this  could  be  projected  as  early  as  first  quarter 
after  conpleting  Ed  Plans  (see  page  3.) 

-  Useful  for  notifying  students  if  a  course  is  to  be 
cancelled  -  to  alert  them  and  advisor  to  revise  Ed 
Plans. 

-  Useful  for  determining  number  of  books  to  be  ordered 
(insure  as  to  vdio  really  determines  the  number  of 
ordered  texts) . 

-  To  assist  instructor  book  ordering  and  roan  scheduling 
—  Subj,  Number  of  Students  Scheduled  Per  Quarter. 

USER  FRIENDLY 

1.  An  interactive  system  to  list  any  discrepancies  within  a  stu¬ 
dent  Ed  Plan  to  alert  the  advisor  of  possible  problems.  Flags 
inconsistencies  and  displays  them  at  the  end  of  the  autcmated 
'checker'  for  the  user. 

2.  Present  database  is  difficult  to  work  with  and  does  not  pro¬ 
vide  sufficient  'help'  to  quickly  navigate  within  system. 

3.  Lower  case  letters  cure  not  recognized  in  areas. 

4.  The  menu  does  not  follow  Itself  (it  asks  for  a  choice  of  'L' 
or  'S',  for  example,  when  it  really  wants  a  number;  it  does 
not  tell  you  vAen  the  disk  vAiich  contains  the  database  is  not 
accessable) . 

FACULTY 

1.  Teaching  Loads  -  obtain  individual  or  entire  list  of  faculty 
teaching  loads  (MANAGEMENT  TOOL  section) . 


OTHER  TOOLS 


*  Recognize  restricted  courses  from  48  hour  total: 

EE  545,  EE  560,  EE  562,  EE  572,  EE  573,  any  Systems 
Management  (to  include  Operational  Sciences  also) 
and  CT  courses; 

*  Determine  GPA*s:  (See  page  2) ; 


1.  Determine  Future  Class  Sizes  and  thus  determine  instructor 
work  load  manpol^^er  requiraients;  archive  ability. 

2.  Thesis  data  ^  student  ccxisisting  of  -  ccmnitte  members, 
title. 

3.  Class  data  -  heme  telephone  numbers,  box  numbers,  all  data 
by  COURSE. 

4.  By  project  within  a  class  for  team  reports  -  NAME,  Social 
Security  Number  (SSN) ,  SERVICE,  RANK,  BOX  NUMBER,  HOME  TELE¬ 
PHONE  NUMBER,  CLASS  (GCS-84D,  etc.) . 

5.  Conpilation  of  statistics  and  data  on  classes  an  instructor 
has  taught  (when  taught,  average  grades,  history  of  students 
vAio  were  in  classes)  to  serve  as  an  instructor  grading  prac¬ 
tices  history: 

-  Put  all  grades  in  computer  for  classwork;  keep  track 
of  exams  students  take,  weight  of  each  exam,  hanework 
grades,  pop  quiz  grades,  project  grades  and  weight  of 
each  toward  overall  grade;  produce  averages  -  for  a 
given  grade,  student,  quarter  and  overall  grade. 

-  Pattern  grading  program  after  'Class'  program  many 
instructors  use  new.  Security  is  an  issue  here,  espe¬ 
cially  if  students  are  going  to  be  allowed  access. 

-  A  means  of  producing  a  sunmary  of  student's  course 
grade  to  date,  with  standard  deviation  per  exam,  perti¬ 
nent  data  per  exam  with  listed  histogram  of  exam  and 
standing,  perhaps,  within  class;  this  is  done  for  each 
student  throughout  course. 

-  Ability  to  search  for  students  who  are  doing  poorly 
(be lew  a  certain  avg)  in  course. 

-  Menu  driven  syst^i  to  help  user  wi.th  on-line  help 
facility. 

6.  Interaction  -  Restrict  the  number  of  individuals  with  access 
to  the  database  to  Secretaries  or  selected  individuals  only 


6 .  A  routine  to  CHANGE  any  perscxial  history  Data  like  RANK  within 
each  master  data-set. 

7.  ^  enforcement  policy  to  keep  track  of  who  has/has  not  i^idated 
Ed  Plan  —  advisor,  student  with  date. 

8.  Instructors  should  be  able  to  input  final  course  grades  which 
autonatically  i:^3dates  Ed  Plan. 

9.  Seme  example  queries: 

-  What  is  student's  running  GPA  at  any  given  point  -  some 
instructors  need  this  for  undergraduate  requirements. 

10.  Ability  to  find  student,  his  advisor,  box  number,  claiss  he  be¬ 
longs  to,  thesis  topic,  ^dio  is  on  thesis  ccramittee,  sequences 
he  is  taking  —  some  of  this  data  is  not  within  Ed  Plan  form. 

11.  Able  to  flag  prerequisites  -  those  not  met  or  waived. 

12.  Verifies  all  degree  requirements :  Check  sequence  entries  on 
Ed  Plan  to  insure  all  required  courses  are  entered  for  a 
particular  sequence  - 

-  Devise  management  tool  to  check  all  entries  on  Graduate 
Credit  Record  form  (AFIT  form  89) ; 

*  ability  to  tag  courses  for  proper  placement  on 
official  forms  —  broken  out  by  sequences,  if 
appropriate; 

Like: 

*  Thesis  listed  with  12  credit  hours; 

*  Math  credits  coroposed  of  2  approved  graduate 
courses  v^iich  are  not  progranming  math  courses; 

*  Sequence  courses,  hours  and  grades  (at  least  7 
hours  per  sequence,  but  both  must  equal  minimum  of 
17); 

*  Other  graduate  level  courses  (so  that  their  total 
is  48-52  hours;  based  on  adding  all  graduate 
courses  to  that  line) ; 

*  All  other  courses  (CT  6. XX,  undergraduate,  and  EE 
6.98,  etc.;  there  is  a  list  in  Department  hand¬ 
out)  -  so  that  total  of  all  courses  is  between 

70  -  76  (?) ; 
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*  Listing  of  other  courses  -  total  min.  of  70 
hours  (?) 


*  Check  ALL  against  LEGAL  courses  -  checJcs  for 
spelling  errors 

-  Faculty  Advisor  should  be  able  to  update  Ed  Plan 

-  System  able  to  flag  incc^sistencies  &  list  at  end  of 
autonated  'checker'  for  user  to  utilize 

(*)  Instructor  Statistics 

-  What  courses  taught 

-  Which  quarter  taught 

-  Students  taught 

-  Grades 

(**)  Rocm  usage  program  -  to  assist  INA  planning  quarter  and 

use  during  quarter 

(*)  Security/Integrity 

-  Instructor  wants  access  to  data  frcm  his  terminal  - 
highly  interactive/  yet  protected  (SECURITY) 

-  Grades 

-  Social  Security  Number 

-  Any  other  data  covered  by  Privacy  Act 
(***)  Course  Grading 

-  Determine  by  Student:  Grade  by  veight  for  each  exam, 
hcmework,  project,  quiz,  Avg.  Grade,  STUDEJSiT  DEVIA- 
TICN,  Histogram,  Standing  within  course 

-  Ability  to  query  for  particular  student  in  a  course 
CFv  those  beloiv  a  pcu:i:icular  average 


Appendix  E 

Original  AFITDB  Data-set  Items 


These  are  the  Data-sets  of  the  original  AFIT  Database  (this  file 
found  in  AFITDB. DBG) .  Shown  eure  the  data-set  name  and  each  data-item  con¬ 
tained  within  it.  Each  data-item  is  listed  in  the  order  it  appears  in  its 
data-set  within  the  Data  Bctse  Generaticxi  (AFITDB. DBG)  document.  Within 
sane  data-sets  there  are  obvious  duplications  and  seme  data-items  are 
listed  by  their  four  letter  abbreviations  only,  since  there  is  no  documenta¬ 
tion  to  further  define  what  the  field  was  intended  to  contain. 


MASTER  FACULTY  FILE 

FACT  -  Faculty  Social  Security  Number 

-  Marital  Status 

-  Name 

-  Civil  Service  grade 

-  MBRH  (no  specification) 

-  Office  roan  number 

-  Address 

-  Office  phone  number 

-  Home  phone  number 

-  Date  of  Birth 

-  Name  of  Spouse 

-  Mil/Civ  rank 

-  Date  hired 

-  Air  Force  Specialty  Code 

-  Salary 

-  RDAT  (no  specification) 

-  RSTA  (no  specification) 

MASTER  STUDEM'  FILE 

STDT  -  Student  Social  Security  Nunher 

-  Sex 

-  Name 

-  Mil/Civ  rank 

-  Box  number 

-  Duty  Air  Force  Specialty  Code 

-  Primary  Air  Force  Specialty  Code 

-  Hone  phcaie  number 

-  Duty  phone  number 


-  Education  code 

-  Date  of  rank 

-  Date  of  contnission 

-  Date  of  birth 

-  Place  of  birth 

-  Current  address 

-  Elnergency  address 
"  Spouse  first  name 

-  Spouse  date  of  birth 

-  Number  of  dependents 

-  Military  Service 

-  Race 

-  Religion 

-  Aero  rating 

-  Losing  ccnmand 

-  Military  Spouse 

-  Years  of  Service 

-  Last  Organization 

-  Last  position  title 

-  EXiration  of  Icist  duty  assignment 

MASTER  SECTIOJ  NUMBER  FILE 

SECT  -  Student  class  section  designation 

-  Section  Leader  Social  Security  Number 

-  Secticxi  graduation  date 

-  Section  entry  date 

-  Secticxi  Leader  Social  Security  Number 

MASTER  COURSE  FILE 

MCRS  -  Coiirse  number 

-  Course  credit  hours  data 

-  Course  lecture  hours  data 

-  Course  lab  hour  data 

-  Size  limit  data 

-  Title  data 

MASTER  C3UARTER  FILE 

MQTR  -  Quarter  number 

-  Quarter  stcurt  date 

-  Quarter  stop  date 

VARIABLE  SECTICN  LEADER  FILE 

SECL  -  (Links  only) 

VARIABLE  QUARTER  FILE 

VCQR  -  Code  'QC'  (no  specification) 

-■  Coded  'QS'  (no  specification) 


Appendix  F 

Data-set  Requirements  Tabulations 


Hie  left  side  of  this  24)pendix  lists  the  specific  requiranents 
requested  that  the  expanded  AFIT  Database  acccmnodate,  vMle  the  right 
side  shCKvs  the  subsequent  location  where  the  requirement  hcis  been  in¬ 
cluded  within  it.  The  data  requirements  obtained  by  'interviews'  also 
consisted  of  the  repeat  conversations  with  administrative  perscxinel  as 
well  as  those  originally  interviewed.  This  document  weis  used  to  check 
the  requirements  requested  against  the  atonic  values  needed  to  support 
those  requests.  Those  requirements  items  which  have  more  than  one 
data-set  listed  as  the  location  where  the  requirement  is  found  indicate 
that  either  area  could  contain  such  data  depending  on  the  application 
program  or  that  the  ^plication  program  required  to  obtain  such  data 
can  do  so  utilizing  the  listed  data-set  links.  This  data  is  contained 
in  file  Appendix. F;l. 

RE0UIR£MEI'1T  data  -  OBTAINED  FROM  IMIERVIEWS  TABLE  DATA  -  tfflERE  THE 

RBQUIRByiENTS  DATA  ARE 
LISTED  IN  THE  DATA-SETS 

1.  Change  the  thesis  default  course  credit  MCRS  -  Course  control 
from  4  to  any  number  of  hours  Number  hcis  six  digits 

(EX.  EE799A  -  for  1 

credit  hr; 

EE799B  -  for  2 
credit 
lirs.) 

Linked  to  FACT, 
STDT,  SECT 
Linked  to  FACT, 
SILT,  THES 


3. 

Thesis  Data  — >Student 

STDT 

Advisor 

TADV 

Box  Number 

STDT 

Class 

SECT 

Thesis  Tc^ic  (Title?) 

THTL 

Committee  Members 

TCMF 

Thesis  Title 

THTL 

4. 

Instructors  with  Course  Listings  — > 

Instructors 

FACT 

Course  Listing 

MCRS 

2.  Faculty  Advisor  — >Students  FADV  - 

Faculty  Advisor  — >Thesis  students 
Student  — >Faculty  advisor  TADV  - 

Student  — >Thesis  advisor 


5i  Course  Listing  — > Title 

MCRS 

Course  NuirJber 

MCRS 

Number  Credit  Hours 

MCRS 

Quarter 

MQTR 

Course  Text 

MBKT 

Instructor 

VINS 

6.  Projected  Enrollments 

— ^>Course 

MCRS 

Number  Students 

SCHD 

Quarter 

MQTR 

Number  of  Books  bo  Order 

VNMO 

7.  Ed  Plan  — >Student  Name 

SIDT 

SSN 

STDT 

Course 

(Number  &  Title) 

MCRS 

Section 

(Size  limit  data) 

MCRS 

Credit  Hours 

MCRS 

Class 

SECT 

Quarter 

MQIR 

Grades 

CRSE 

Prerequisites 

MREQ 

Weaver 

CRSE 

Course  Sequences 

MSSF 

8.  Teaching  Loads  ~>a. 

Instructor (s)  Name(s) 

FACT 

b. 

Course (s)  Taught 

MCRS/VCCR 

c. 

Quarter 

MQIR 

d. 

Type  of  Course  -  Lecture/Lab  MCRS 

e. 

Number  of  Sections 

**MCRS 

f . 

Number  of  Theses/ 

Instructor 

FACT/TADV/THES 

g. 

Short  Term  Hours  Taught 

MCRS/FACT 

h. 

Professicaial  Develcpnent 

Quarter  Listing 

VPDQ 

i. 

Faculty  Advisor  Listing 

FADV 

j- 

Thesis  Ccrmittee  Member 

Listing 

tcmf 

**'Size  Limit'  is  data  element 

9.  Course  Data  — >Student  Name 

STCT 

SSN 

STDT 

Service 

STDT 

Rank 

STDT 

Class 

(e.g.,  GCS84D) 

SIDT/SECL/SECT 

Home  Telephone  Number 

STDT 

Box  Number 

STDT 
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FACT 

FACT 

MCRS 


10. 

Instnoctor  Statistics  — >Instrvictor  Name 

SSN 

Courses  Tau^t 

Students  in  Course  by: 

FACT 

FACT 

MCRS 

Name 

STDT 

SSN 

STDT 

Class 

SBCL 

Grades 

CRSE 

11. 

Catalog  Faculty  Publications  — >Name 

FACT 

SSN 

FACT 

Title 

PCCM 

Date 

FCCM 

Tc^ic  (TITLE) 

FCOM 

12. 

Room  Usage  — >Rocin  Location 

BIRM 

Room  Capacity 

CPTY 

Time  Scheduled 

TIME/DAYS/SCHD 

13. 

Projected  Enrollments  — >Course 

MCRS 

Quarter 

MQIR 

Student  SSN 

SIDT 

Student  Name 

STDT 

Student  Class 

SECT 

14. 

Professional  Duties  — >Awards 

FHAW 

Conmittee  Membership 

FCMT 

Conmitbee  Duties 

PCMT 

Professional  Societies 

FSOC 

Interest  Areaa 

FINT 

15. 

Student  Data  — >Name 

STDT 

SSN 

STDT 

Box  Number 

STDT 

Heme  Phone  Number 

STDT 

Advisor 

TADV 

Class 

SECT 

Service 

STDT 

Graduated  AFIT? 

STDT 

16. 

Graduate  Record  Data  — >Verify  Degree 

Requirements 

^DEG 

Course  Sequences 

MSSF 

Courses 

MCRS 

Math  Credits 
Restricted  Courses 
(EE545,  EE560, 

MCRS 

CTXXX,  Etc) 

MCRS 
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Appendix  G 

AFITDB  Expansim  Items 


The  following  listed  data-set  itans  were  not  specifically  re¬ 
quested  through  the  interview  data-gathering  procedure .  The  items  were 
included  within  the  data-sets  as  anticipated-for-use  data  items.  Each 
set  of  data-items  is  shewn  with  its  parent  data-set  name  listed  to  the 
left.  Those  items  with  asterisks  denote  new  items  in  the  database. 

An  asterisk  to  the  left  of  the  data-set  name  indicates  that  the  entire 
data-set  is  new.  These  data-elements  were  selected  by  cenparing  like 
data-sets  (ex. ,  Student  and  Faculty  Masters)  and  items  previously  pro¬ 
posed  for  inclusion  in  the  AFIT  Database  by  Allred.  All  c3ata-items 
for  each  data-set  are  listed  in  their  entirety  in  AFITDB. DBG.  This 
document  is  in  file  Jppendix.G?!. 


FACT  -  Marital  Status  *DEPT  -  Department  Code 


Mil/Civ  Grade 

Office  Rm  Number 

STDT  -  Sex 

Address 

Duty  AFSC 

Office  Phone 

Primary  AFSC 

Have  Phene 

Duty  Phone  Number 

DOB 

Edxacation  Code 

Sex 

DOR 

Duty  AFSC 

Ccnitdssioning  Date 

Primary  AFSC 

DOB 

DOR 

Place  of  Birth 

Emergency  Address 

Current  Address 

Number  of  Dependents 

Emergency  Address 

Service 

Spouses  Name 

Race 

Race 

Religion 

Religion 

Aero  Rating 

Aero  Rating 

Cemmissioning  Date 

Number  of  Dependents 

Last  Organization 

Last  Organization 

Last  Position  Title 

Last  Position  Title 

Spouses  Name 

Last  Command 

Date  Hired 

Military  Spouse 

Expected  AFIT  Departure  Date 
Spouses  DOB 

Graduated  AFIT 

*AIM1  -  (NTIC  Number  -  For  Thesis 
Cataloging) 

Thesis  Code 


SECT  -  Section  Leader  SSSN 
Graduation  Date 
AFIT  Entry  Date 
Number  in  Section 


MCRS  -  Restricted  Course 


MCTR  -  Quarter  Start  Date 
Quarter  End  Date 
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MBKT 


*MCRD 


-  Book  Author  Name 
Book  Publisher  Name 
Number  Books  Available 
Price 


MSSF  -  Course  Sequence  Number 


(Book  Ordering  Info) 
Order  number 
Due  Date 
Ccitpany 

Ccnpany  Address 
Catpany  Phme  Number 
Cotpany  Phone  Area  Code 

MDEG  -  Nunber  ID  Type  Grad  Deg 


*VEDU  -  (Variable  Education  File) 
Institution  (University) 
Attended 
Degree  Earned 
Year  Degree  Awarded 

*VHAW  -  (Vcuriable  Honors  and 
Award  File) 

Honor  Received 
Date  Honor  Received 
Award  Received 
Date  Award  Received 


**This  is  a  combination  of  two 
♦♦previous  data-sets,  FEDU  & 
♦*DGYR. 


♦♦This  is  a  catibination  of  toro 
♦♦previous  data-sets,  FHAP'J  & 
♦♦AWAR. 


FCCM 

-  Co-author  Name 
Publicaticai  Date 
Presentations  s 
0rgani2ation 

Date  of  Presentation 

♦ETDY 

-  (TDY  File) 

Cost  of  Trip 
Destination 

Begin  Date 

End  Date 

CRSE 

-  Course  Credit 

Course  Number 

Course  Name 

Grade 

THTL 

-  Thesis  Sponsor 

Thesis  Location 

Thesis  Classification 

Course  Begin  Date 

Course  End  Date 

College  Attended 

VREO 

-  Corequisite 

VTXT 

-  Description  of  Book 
Outline  of  Book 

SCHD 

-  Class  Finish  Time 

♦CLSR 

-  Additional  Space  If  Extra 

Chairs  Needed 

Type(s)  Equipment  In  Roan 

Type  of  Room  Code 

Room  Security  Classification 
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Appendix  H 

Requirements  Presentations 


Utilizing  the  information  from  Appendices  D,  E,  and  F,  antici¬ 
pated  ^plication  programs  requirements  are  listed  to  provide  addi¬ 
tional  anticipation  of  future  database  enhancesients.  The  requirements 
presentation  itens  are  in  the  left  column  vd.th  the  anticipated 
^jplication  program  requirements  irmediately  to  their  right.  Some  of 
the  afplications  programs  were  specifically  requested  in  the  interview 
process  vhile  others  reflect  anticipated  related  requests.  This  shews 
the  relaticaiships  between  the  requirements  portion  and  the  applica¬ 
tions  programs  (yet  to  be  developed) .  The  original  document  is  in  file 
Appendix.H;!. 


Requirements  Presentations 
1 .  Teaching  Loads 

by:  1)  Individual 
£ 

2)  Department 


2.  Ed  Plan 


3.  Graduate  Record  Data 
(Verify  degree  requirements) 


Applications  Programs 

1.  Show  Number  of  short  course 
hours  taught  -  by  individxaal 
and  department 


2.  Determine  Number  of  thesis 
cottmittees  faculty  menber 
is  on. 

3.  Determine  number  of  theses 
faculty  member  sponsors. 

4.  List  professional  develop¬ 
ment  quarters  by  faculty 
menber  and  quarter. 

5.  Verify  entered  course, 
quarter,  prerequisite  and 
show  errors  (with  print 
option)  for  use  with  other 
application  programs. 

6.  Printout  of  Ed  Plan  with 
grades 

7.  Check  sequence  entries  for 
preper  courses. 

8.  Determine  GPA  (4)  routines 


4.  Project  Enrollment 


9.  List  numbers/naraes  of  stu¬ 
dents  progranitied  to  take  all 
classes  for  fiscal/calender 
year 

10.  List  numbers/names  of  stu¬ 
dents  prograrrmed  to  take  one 
class. 

5.  Instructor  Statistics  11.  Provide  history  of  courses 

taught  by  individual  faculty 
members. 

12.  Provide  listing  of  students 
taught  by  individual  faculty 
members  by  course  and  their 
grcides. 

6.  Room  Usage  13.  Determine  c^tiinum  roan  usage 

plan  for  quairter. 

7.  Course  Index  14.  List  course  information 

(quarters  course  taught, 
instructor,  text  used,  credit 
hrs,  title,  nimiber) 

15.  Provide  info  to  user  like 

name,  advisor,  thesis  advisor 
box  niamber,  home  phone,  duty 
phone,  class,  thesis  topic, 
thesis  comnittee  members. 

9.  New  Student  Data  16.  Input  new  student  data  to 

database. 


8.  Quick- look-up 

of  Student  Pertinent 
Information 
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AFITDB  Forms  Library  Listing 


The  follcwing  is  a  coipilaticn  of  the  FMS  form  screens  contained 
within  the  library  v^ch  supports  the  AFITDB  database.  Each  screen 
must  reside  within  a  library  in  order  to  require  only  one  opening 
statanent  within  the  calling  routine.  Failure  to  provide  a  library 
from  which  to  call  IMS  screens  would  require  extensive  opening  and 
closing  for  each  form  utilized  by  an  application  within  the  driver. 

The  three  column  format  is  produced  using  the  FMS  form  utility  (FUT) . 
The  'Form  (VERSION) '  column  lists  each  form  name  with  it's  correspond¬ 
ing  latest  version  number.  The  author  added  the  version  number  head¬ 
ing  and  numbers  (shown  in  pcurenthesis  immediately  following  the  'Form' 
HEADING  and  each  form  name)  to  use  as  a  reference  vrfnen  updating  the 
library.  The  date  column  lists  the  latest  date  changes  were  made  to 
each  form,  vAiile  column  three  shews  the  work  space  area,  in  bytes, 
reserved  for  each  screen  within  the  FMS  driver  work  space  area. 

FUT  Vol.l 
19-Oct-84 

Library  DUl;  [PANGMAN.MIKEDB.  TOTAL)  MIKELIB2.FLB;42  created:  19-Oct-84 
Directory  is  1  blocks  long 


Form  (VERSION) 

Date 

Inpure  area  (bytes) 

TIME(l) 

l-Sep-84 

290 

FIRST1(4) 

21-Sep-84 

383 

VREO(l) 

l-Sep-84 

307 

SCHEDUO) 

7-Sep-84 

369 

LASFACO) 

6-Sep-84 

309 

TEXTBK(4) 

7-Sep-84 

371 

M0DATA(5) 

7-Sep-84 

451 

VMSS(2) 

12-Sep-84 

515 

UTILIT(6) 

20-Sep-84 

387 

STDT(13) 

26-Sep-84 

2791 

GCR1(3) 

21-Sep-84 

2288 

G0R2(3) 

2 l-Sep-84 

1426 

CRSE(5) 

19-Oct-84 

977 

THTL(6) 

2 l-Sep-84 

1061 

FS0C(6) 

21-Sep-84 

514 

VEDU(6) 

2 l-Sep-84 

620 

VHAW(4) 

21-Sep-84 

712 

FACT  (9) 

2 l-Sep-84 

2576 

pciyrr(5) 

21-Sep-84 

788 

PC0M(5) 

2 l-Sep-84 

800 

FINT(4) 

2 l-Sep-84 

469 

FTDY(5) 

2 l-Sep-84 

695 

MBKT(4) 

21-Sep-84 

1017 

M0RD(5) 

21-Sep-84 

826 

RCXM(5) 

21-Sep-84 

665 

DEPT (7) 

21-Sep-84 

493 

SECT  (5) 

21-Sep-84 

704 

OiASO) 

21-Sep-84 

704 

MCRS(9) 

21-Sep-84 

840 

MQTR(3) 

21-Sep-84 

543 

MDBG(3) 

21-Sep-84 

499 

S'IUFAC(6) 

21-Sep-84 

363 

FACLTY(5) 

21-Sep-84 

453 

BEGIN (2) 

21-Sep-84 

271 

STUIM'(IO) 

21-Sep-84 

373 

MSSF(3) 

21-Sep-84 

490 

MIKE1(4) 

21-Sep-84 

297 

ET^9A(2) 

19-Oct-84 

2441 

FRM29B(2) 

19-Oct-84 

2441 

ERM29C(2) 

19-Oct-84 

2441 

FRM29D(2) 

19-Oct-84 

2441 
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AFITDB  DEMONSimTICN  MENU 


Faculty  Professional  Memberships 


the  Following  Data: 


Faculty  TDY  Data 


(0 


2  ^ 

Ot  O' 


(0  in 


■y  < 

w 

0)  (U 


■u  o 


Faculty  Professional  Interest  Data 


Individual  Education  File 


8 


Figure  1-16.  Individual  Education  Data 


Individual  Honors  and  Awards  Listing 


Figure  1-17.  Individual  Honors  and  Awards  Data 


Textbook  Data 


Textbook  Ordering  Information 


Figure 


lTULATICWS  ! !  You  Found  the  Scheduling  Capability 


m  o 

OJ  i-H 

•H  p 

CO  b 


^  B 

■S  ^ 

cn 

qj  CO 

ffl  3 


<0  0) 


o  q 

-H  4J 


2  5  .ti 

^  S  S 

CN  00  CTi 


Selection  Form 


r  ^ 


I 

(o  *• 


05 


05  <U 


05  M-t  O-l 
•H  O  O 

+J  0)  fl) 

ill 


CNJ  ro  LD  V£> 


Scheduling  Data 


Class 


Class  Start  Tijnnes 


^K)DATA'  Menu  Selection  Form 


BS 


Enter  the  Following  Class  Data: 


. 

O  VO 


I  ii 

S'  ^ 

4J 

•H  C 


4J  CO 

fd 

&  ^ 


8  cn 

ca  M 


M  •-< 

m  u 


a 

a 

3 

J-l 

3 

w 

w 

'p 

w 

cn 

P 

cn 

cn 

0 

0] 

-9 

cn 

>• 

(d 

(d 

x; 

to 

S 

(d 

fH 

fH 

u 

pH 

Q 

o 

u 

ca 

u 

2 

u 

Q 

• 

• 

• 

• 

• 

• 

• 

fH 

rvj 

CO 

LO 

VO 

student  Class  (Section) Data 


Enter  the  Following  Quarter  Data: 


-29.  Master  Quarter  Input  Data 


VARIABLE  THESIS  COMMITTEE  ME>1BER  FILE 
TCMF  -  (Links  only) 

VARIABLE  FACULTY  ADVIS®  FILE 
FADV  -  (Links  only) 

VARIABLE  INSTRUCTOl  STATISTICS  FILE 
VINS  -  (Links  only) 

VARIABLE  THESIS  ADVISOR  FILE 
TADV  -  (Links  only) 

VARIABLE  PROFESS  lOSIAL  DEVELOHyiENT  FILE 
VPDQ  -  (Links  only) 

VARIABLE  SEQUENCE  FILE 

VMSS  -  Lists  which  courses  belong  in  sequence 


1 
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VARIABLE  SBCTICN  LEADER  FILE 
SECL  -  (Links  only) 


VARIABLE  QUARTER  FILE 

VCQR  -  Coded  'QC'  (Course  data) 

-  Fill  data 

-  Coded  'OS'  (Student  data  -  link) 

-  Grad  data 

-  Coded  'FQ'  (Faculty  data  -  link) 


VARIABLE  REQUISITE  FILE 

VREQ  -  Coded  'CR'  (Code  is  corequisite) 

-  Requisite  course  nuntier 
-  Coded  'PR'  (Code  is  prerequisite) 

-  Requisite  course  number 


VARIABLE  TEXT  FILE 

VTXT  -  Coded  'DS'  (Code  is  description) 

-  Description  data 
-  Coded  'QL'  (Code  is  outline) 

-  Outline  data 


VARIABLE  BOOK  LINK  FILE 
VCBK  -  (Links  only) 


VARIABLE  NUMBER  ORDERED  FILE 
VNMO  -  Book  title  control  field 


'variable  CLASS  SCHEDULE  FILE 

SCHD  -  Number  of  students  in  class 
-  Class  finish  time 


'variable  classroom  file 

CLSR  -  Type(s)  of  equipment  in  roan 

-  Code  for  type  of  room 

-  Code  for  security  classification  level  of  roar, 
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VARIABLE  HCKCaRS  AND  AWARDS  FILE 


NHAW  -  Coded  'HN'  (Honor  Area) 

-  Honors  received 

-  Date  honor  received 
-  Coded  'AW'  (Award  Area) 

-  Awards  received 

-  Date  award  received 


VARIABLE  FACULTY  INTERESTS  FILE 
FINT  -  Area  of  interest 


VARIABLE  FACULTY  PUBLICATIOSFS  AND  PRESENTATICNS 

FCCM  -  Coded  'PB'  (Publication  data  area) 

-  Title  of  publication 

-  Date  of  publication 

-  Naine(s)  of  co-authors 

-  Coded  'PR'  (Presentations  data  area) 

-  Presentation  given  to  this  organization 
(give  organization) 

-  Presentation  date 


VARIABLE  FACULTY  TDY  FILE 

FTDY  -  Cost  of  TDY  data  in  this  file 

-  Destination 

-  Begin  date 

-  End  date 


VARIABLE  STUDENT  COURSE  FILE 

CRSE  -  Course  number 

-  Course  name 

-  Course  grade 

-  Quarter  student  took  or  will  take  course 

-  College  attended 

-  Course  waived  (Y/N) ? 


VARIABLE  THESIS  TITLE  FILE 

THTL  -  Thesis  title 

-  Thesis  sponsor 

-  Thesis  location 

-  Thesis  clcussification 
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MASTER  BUILDING/ROCM  FILE 


Bli^  -  Building  and  rocm  number 

MASTER  ROCM  CAPACITY  FILE 
CPTY  -  Capacity  number 

MASTER  DAY  SCHEDULING  FILE 
DAYS  -  Day  of  the  \ieek 

MASTER  SEQUENCE  FILE 

f^SF  -  Course  sequence  nui±)er 

-  Sequence  name 

MASTER  DEGREE  REQUIREMENTS  FILE 

MDEG  -  Number  identifying  type  grad  degree 

-  Name  of  type  of  degree 

VARIABLE  EDUCATICN  FILE 

VEDU  -  Institution  (University)  attended 

-  Yecu:  degree  awarded 

VARIABLE  FACULTY  SOCIETY  FILE 

FSOC  -  Societies  to  which  individual  belongs 


VARIABLE  FACULTY  DEPARTMENT  AND  CCMMITTEE  FILE 

FCMT  -  Coded  'DP'  (Ccnnittee  membership) 

-  Name  of  committee 

-  Name  of  department 

-  Coded  'CM'  (Additional  coninittee  memberships) 

-  Name  of  other  canmittee 

-  Name  of  other  department  (if  different) 
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MASTER  THESIS  NUMBER  FILE 
THES  -  Thesis  cataloging  number 


MASTER  SECTICN  NUMBER  FILE 

SECT  -  Secticxi  number  (ex.,  QCS-84D) 

-  Section  leader  Social  Security  Number 

-  Graduation  date 

-  Entry  date 

-  Number  of  students  in  section 


MASTER  COURSE  FILE 

MCRS  -  Course  number 

-  Course  credit  hours 

-  Course  lecture  hours  data 

-  Course  lab  hour  data 

-  Size  limit  data 

-  Title  data 

-  Restricted  (fron  grad  requirements)  course? 
MASTER  QUARTER  FILE 

MQTR  -  Quarter  number 

-  Quarter  start  date 

-  Qucirter  stop  date 


MASTER  BOOK  FILE 

MBKT  -  Book  title  name 

-  Book  author  name 

-  Book  publisher  name 

-  Number  of  books  available 

-  Book  price 


MASTER  ORDER  FILE 

^OlD  -  Master  order  number 

-  Order  number 

-  Due  date 

-  Carpany  order  is  with 

-  Company  address 

-  Carpany  phone  number  with  area  code 


MASTER  CLASS  TIME  FILE 
TIME  -  Militciry  clock  time 


-  Office  phone 

-  Last  organization 

-  Last  position  title 

-  Expected  AFIT  departure  date 


MASTER  DEPARIMEin?  FILE 

DEPT  -  Department  code 
-  Department  name 


MASTER  STUDENT  FILE 

STDT  -  Student  Social  Security  Number 

-  Name 

-  Mil/Civ  Rank 

-  Has  student  already  graduated/ left  AFIT? 

-  Military  Service 

-  Aero  rating 

-  Date  of  rank 

-  Date  of  ccmnission 

-  Years  of  service 

-  Sex 

-  Box  number 

-  Duty  AFSC 

-  Primary  AFSC 

-  Current  address 

-  Einergency  address 

-  Home  phone 

-  Duty  phone 

-  Education  code 

-  Date  of  birth 

-  Place  of  birth 

-  Marital  status 

-  Spouse  first  name 

-  Spouse  date  of  birth 

-  Number  of  dependents 

-  Race 

-  Religion 

-  Losing  conriand 

-  Last  organization 

-  Last  position  title 

-  Duration  at  last  duty  assignment 


MASTER  NTIC  NUMBER  FILE 
AENR  -  Thesis  code 
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Appendix  J 

Expanded  AFITDB  Data-set  Items 


The  follcwing  are  the  Data-sets  of  the  expanded  AFIT  Database, 
shewn  by  data-set  name  and  each  data-itan  contained  within  it.  Each 
data-item  is  listed  in  the  order  it  appears  in  its  data-set  within 
the  Data  Base  Generation  (MIKEDB.DBG)  document.  The  less  important 
(to  the  academic  administration)  and  less  likely  changed  data  (spouse 
name,  date  of  birth,  place  of  birth)  is  placed  toward  the  end  of  the 
data-set.  The  order  represents  all  master  data-sets  first  followed  by 
the  variable  data-sets,  since  during  database  generation,  all  refer¬ 
enced  master  data-sets  must  first  be  defined. 


MASTER  FACULTY  FILE 

FACT  -  Faculty  Social  Security  Number 

-  Name 

-  Rank 

-  Military  Service 

-  Date  of  Conmission 

-  Date  hired 

-  Salary 

-  Date  of  birth 
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1-32.  Student  Education  Plan  Form  (Form  29A) 
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Figure  1-31.  Utility  Directory 


Sequences 


Figure  1-30.  Ccxirse  Sequence 


Appendix  K 
AFxlDB  I/O  Areas 


The  following  lists  I/O  areas  designations,  nuitiber  of  copies  for 
each  I/O  area,  and  those  data-sets  assigned  to  each  I/O  area.  The  num¬ 
ber  of  copies  for  each  I/O  area  were  determined  based  on  expected  user 
usage  as  determined  from  the  interview  results  listed  in  J^>pendix  B  and 
the  prioritized  listing  of  new  database  requirements  in  i^>pendix  D. 

The  configuration  of  the  data-sets  also  contributed  to  the  final 
determination . 

Each  data-set  with  the  database  is  assigned  a  logical  work-space 
area  known  as  an  I/O  area.  When  a  data-set  or  record  is  to  be  processed 
it  is  placed  into  the  designated  I/O  area.  The  values  of  any  data  ele¬ 
ments  and/or  items  specified  will  be  moved,  one  by  cne,  frcm  the  corres¬ 
ponding  record  fields  in  the  I/O  buffer  to  a  user-defined  data  storage 
area,  like  a  buffer  or  array. 

With  only  a  single  copy  of  an  I/O  area  assigned  to  a  file  or  files, 
buffer  tlirashing  could  occur  with  a  corresponding  itrpact  on  perform¬ 
ance,  Multiple  copies,  if  present,  will  be  allocated  and  used  dynami¬ 
cally  on  a  least  recently  used  basis.  A  number  of  rules  apply  to  I/O 
areas: 

1.  No  duplicate  (I/O  area)  names  are  allowed. 

2.  Each  data-set  may  have  one  and  only  one  I/O  area  eissigned  to  it 
vdien  the  data  set  is  defined. 

3.  A  master  data-set  must  not  share  an  I/O  area  with  a  variable-«3-try 
data-set. 

4.  An  I/O  area  assigned  to  one  and  only  one  data-set  must  be  listed 
and  is  regarded  as  a  private  I/O  area. 

5.  Each  occurrence  of  this  statement  will  reserve  an  area  whether  or 
not  it  is  ever  referenced  in  the  data-set  definition. 

6.  There  is  a  limit  of  ^3  areas  that  may  be  defined. 

7.  A  maximum  of  -2  copies  of  an  I/O  area  is  possible  with  a  default 
of  1. 


(6:4-6) 


Each  I/O  area  is  listed  under  the  left  column  with  the  breakout 
of  the  data-sets  to  their  right.  Multiple  copies  are  designated  by 
the  equals  inmediately  to  the  right  of  the  listed  I/O  area  (ex. ,  MAS3= 
2) .  They  are  subjectively  grouped  according  to  anticipated  use  and 
expected  relatedness  in  future  application  programs.  The  concept  is 
that  heavily  accessed  and  large  data-sets  have  their  cwn  I/O  area  as 
well  as  unrelated  and  smaller  data-sets.  This  breakout  is  expected  to 
assist  in  reducing  extensive  I/O  handling. 

MASTER  I/O 

AREAS 

DATA-SET 

MASl 

MBKT;  MQRD 

MAS2 

DEPT;  AIM^ 

MAS3=2 

MCRS 

MAS4=2 

STDT 

MAS5=2 

FACT 

MAS6=2 

THES;  SECT 

MAS7 

MQTR 

MAS8=2 

MSSF;  MDEG 

MAST 


TIME;  BLRM: 
CPIY;  DAYS 


VARIABLE  I/O 
AREAS 


VARX 

VCQR; 

VREQj 

VTXT; 

VCBK! 

VIMD 

VARl 

VEDU; 

FSOC 

PCMT; 

VHAW 

FINT; 

PCQM 

ETDY 

VAR3=2 

VPDO 

VAR4=2 

SECL; 

TCMF; 

FADV; 

TADV 

VAR5=2 

CRSE; 

THTL 

VAR6=2 

VCQR; 

VI»1SS 

VART 


SCHD;  CLSR 


Appendix  L 

AFITDB  Data-set  Drive  Designations 


Each  data-set  requires  a  specific  disk  area  be  defined  for  use 
during  database  interaction.  The  following  specifies  how  the  drive 
number  and  data-sets  interact  and  lists  the  separate  drive  numbers  for 
each  data-set.  Fodlure  bo  specify  separate  drive  identifiers  causes 
a  logical  error  within  the  initiaticn  of  the  data-sets. 

The  name  of  each  data-set  is  first  listed  with  the  corresponding 
drive  data  following.  The  format  is  'Drive  =  n,n,xxn'  with: 

n  specifies  the  logical  unit  number  to  be  associated  with 

this  section. 

n  specifies  the  number  of  physical  sectors  to  allocate 

with  this  section. 

xxn  specifies  the  device  and  unit  number  to  allocate  this 
section.  In  this  case  *DU1'  indicates  the  drive  which 
contains  the  database  and  DBMS. 

The  logical  unit  number  must  be  unique  within  the  data  base.  Mul¬ 
tiple  drive  statements  may  be  specified  if  the  data-set  requires  more 
than  one  section.  The  maximum  number  of  drive  statements  per  data-set 
is  32.  The  number  of  sectors  used  within  any  section  is  always  a  mul¬ 
tiple  of  the  sectors  per  block.  The  value  of  sectors  per  block  is  cal¬ 
culated  internally  depending  upon  the  values  specified  for  {logical- 
record-length}  and  {logical-records-per-block.}  If  these  two  state¬ 
ments  are  not  included  {DBGEM}  (database  generation  routine)  will  use  a 
default  value  of  1  for  sectors  per  block.  The  number  of  sectors  actu¬ 
ally  allocated  may  differ  fran  the  nxamber  specified.  {DBGEN}  will  only 
allocate  as  much  space  as  defined  by  the  {TOTAL-Logical-Records}  state¬ 
ments.  The  value  for  sectors  may  not  exceed  32,767  (one  less  than  the 
maximum  DBMOD  size)  in  any  one  section 

Therefore,  data-set  'TIME'  is  associated  with  logical  unit  number 
01,  can  have  at  most  5000  sectors  allocated  and  will  reside  on  device 
DUl  (DUAl  -  a  Winchester  drive) .  The  number  of  sectors  was  selected 
to  be  5000  to  insure  adequate  record  space  for  data-set  expansion.  As 
stated  above,  TOTAL  only  allocates  sufficient  space  to  accomodate  the 
anticipated  nurtber  of  stored  records  ({TOTAL-Logical-Records})  .  The 
listing  is  by  logical  number  V'/ith  no  data-set  name  listed  for  unassign¬ 
ed  logical  units  (6:4-20). 

DATA-SET-NAME=TIME  DRIVE=01, 5000, DUl 

DATA-SEr-NAME=BLRM  DRIVE=02, 5000, DUl 


DATA-SET-NAMECPTY 


DRIVE=03, 5000, DUl 


DATA-SET-NAME=DAYS 

DATA-SEr-NAME=SCHD 

DATA-SET^^AME=CLSR 

DATA-SET-NAME= 

DATA-SET-NAME= 

DATA-SETH^AME= 

DATA-SErH^AME= 

DATA-SBr^iAME= 

DATA-SET-NAME=WCRS 

DATA-SET-NAME=^yiQTR 

DATA-SBr-NAME=MBICr 

DATA-SET-NAME=MORD 

DATA-SET-NAME=VCOR 

DATA-SET-NAME=VREO 

DATA-SET^SIAME=VTXT 

DATA-SET-NAME=VCBK 

DATA-SET-NAME=VNMO 

DATA-SEr-NAME=AIMl 

DATA-SET-NAMEXTHES 

DATA-SETT-NAMEXSECT 

DATA-SEH^Hl'IAMEXrHTL 

DATA-SET-NAMEXSEXX 

C!ATA-SErr-NAME=STDT 

DATA-SETT-NAMEXCRSE 

DATA-SET-NAI-IEXAWAR 

DATA-SET-NAMEXDGYR 


DRIVE=04,5000,DU1 
DRIVEX05, 5000,001 
DRIVE=06,5000,DU1 
E»IVE=07,5000,DU1 
DRIVE=08,5000,DU1 
DRIVE=09,5000,DU1 
DRIVE=10,5000,DUL 
DRIVE=11,5000,DU1 
DRIVEX12, 5000,001 
DRIVEX13, 5000, 001 
ORIVEX14, 5000, 001 
ORIVE=15, 5000, 001 
ORIVEX16, 5000, 001 
DRIVEX17, 5000, 001 
miVE=18, 5000, 001 
DRIVEX19, 5000, 001 
DRIVEX20, 5000, 001 
ORIVEX21, 5000,001 
ORIVE=22,5000,D01 
DRIVEX23, 5000, 001 
ORIVE=24, 5000, 001 
ORIVE=25, 5000,001 
ORIVEX26, 5000, 001 
ORIVEX27, 5000, 001 
ORIVE=28, 5000, 001 
ORIVEX29, 5000, 001 
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DATA-SET-NfiME=FACr 


DATA-SET-NAME=DEPT 

DATA-SET-NAME=FEDU 

DATA-SET-NA^IE=FSOC 

DATA-SET-NAME=PCMT 

DATA-SET-NAME= 

DATA-SEmAME=FHAW 

DATA-SET-NAME=FINT 

DATA-SET-NAME=FCayi 

DATA-SET-NAME=FTDY 

DATA-SET-NAME=VSEO 

DATA-SETH^AME=^EO 

DATA-SET-NAME=44SSF 

nATA-SET-NAME==MDEG 

DATA-SET-NAME==TCMF 

DATA-SEr-NAME=FADV 

DATA-SET-NAME=VINS 

DATA-SET-NAME=TADV 

nATA-SETHSIAME=VPDO 


DRIVE=30,5000,DU1 

DRIVE=31,5000,DU1 

DRIVE=32,5000,DU1 

r»IVE=33,5000,DUl 

DRIVE=34,5000,DU1 

DRIVE=35,5000,DU1 

DRIVE=36,5000,DU1 

ERIVE=37,5000,DU1 

DRIVE=38,5000,DU1 

DRIVE=39,5000,DU1 

DRIVE=40,5000,DU1 

DRIVE=41,5000,DU1 

DRIVE=42,5000,DU1 

DRIVE=43,5000,DU1 

DRIVE=44,5000,DU1 

DRIVE=45,5000,DU1 

DRIVE=46,5000,DU1 

DRIVE=47,5000,DU1 

DRIVE=48,5000,DU1 

DRIVE=49,5000,DU1 


DATA-SET-NAME=^VMSS 


;^pendix  M 

Functional  Requirenents  and  System  Design  Documentation 


The  following  represents  the  functional  requirements  determined 
initially  during  the  analysis  stage  of  the  project.  The  four  major  head~ 
ings,  itvEurked  by  the  integer  numbered  itens  1.0  through  4.0,  show  the  pro¬ 
cesses  determined  to  be  of  prime  importance  during  the  testing  of  the 
Driver  and  follow-on  ^plication  programs. 

1.0  Establish  a  user  interface 

1.1  Log  on  database  properly 

1.2  Allow  user  to  select  type  of  database  operation 

1.3  Allow  user  to  inspect  selection 

1.4  Allow  user  to  specify  either  faculty  or  student  database  use 

1.5  Allow  user  to  specify  types  of' utility  to  be  conducted 

1.6  Allow  user  to  add/change/modify  data 

2.0  Set  up  selected  data  manipulation  routine 

2.1  Create  or  initialize  data  files 

2.2  selected  utility  to  proper  application  program 

2.3  Minimize  the  amount  of  variables,  links,  data  sets  looked  at 
during  da-ta  manipulation 

2.4  Return  error  sta-tus  to  user 

3.0  Close  out  the  da-ta  session 

3.1  Allow  user  to  gracefully  terminate  session 

3.2  Deallocate  resources 

3.3  Return  error  sta'tus  to  user  to  forestall  unnecessary  delays 
in  database  usage 

3.4  Log  off  database  properly 

4.0  Present  data  to  user 

4.1  Create  output  forms 

4.2  Print  output  forms  by  user  selected  device 

4.3  Display  output  data  on  terminal 

(22) 

Throughout  the  coding  and  implementation  of  -the  Driver  program,  test 
procedures  were  conducted  using  the  individuals  who  had  been  interview 
subjects  at  the  beginning  of  this  project.  When  warran-ted,  additional 
changes  to  design  were  made  cifter  such  discussions  (such  as  allowing  -the 


user  to  exit  the  Driver  program  prior  to  the  'Firstl'  screen,  before 
the  'Signon'  procedure). 

Such  test  procedures  were  arrainged  into  test  modules  in  order 
to  process  an  orderly  code  test  procedxire  within  the  project.  The 
functional  requirements  specified  in  the  first  portion  of  this  ajpen- 
dix  are  the  basis  of  the  test  plan  presented  herein. 


SYSTEM  DESIGN  DCCUMEm’ATICN 


TEST  PLAN 


rEXXIIREMEMT:  1.1  -  Log  on  database  prc^rly. 

TEST  CASE (S) : 

1.  Attenpt  log-on  without  activating  TOTALINIT. 

2.  Attenpt  log-on  without  TOTPRM. 

3.  Attenpt  log-on  with  files  locked. 

4.  Attenpt  log-on  without  Schema  defined. 

EXPECTED  RESPCNSE: 

1.  Program  will  run  without  database  interaction. 

2.  'Database  not  found'  will  be  returned  to  program. 

3.  Trying  to  load  locked  files  will  return  lock  error. 

4.  Log-on  will  cause  catestrophic  failure  and  conplete  unload 
of  attatpted  operation. 

RESULTS; 


CASE 

1.  -  PASS; 

FAIL; 

DATE; 

CASE 

2.  -  PASS; 

FAIL; 

DATE; 

CASE 

3.  -  PASS; 

FAIL; 

DATE; 

CASE 

4.  -  PASS; 

FAIL; 

DATE; 

TESTED  BY; 


REvlARKS; 


SYSTEM  DESIGN  DOCUMENTATia'I 


TEST  PLAN 


REQUIREMENT:  1.2  -  Allcw  user  to  select  type  of  database  operation. 
TEST  CASE(S)  : 

1.  No  selecticai  entered. 

2.  Wrong  type  data  entered. 

3.  'Exit*  selected. 

EXPECTED  RESPONSE: 

1.  Unless  'Exit'  selected,  user  unable  to  advance  until 
proper  response  made. 

2.  Data  not  accepted  for  input,  terminal  signals  this 
to  user  in  form  of  bell. 

3.  If  choice  is  'Exit',  shut  down  database  and  log  off. 
RESULTS: 

CASE  1.  -  PASS: _  FAIL: _  DATE: _ 

CASE  2.  -  PASS: _  FAIL: _  DATE: _ 

CASE  3.  -  PASS: _  FAIL: _  DATE: _ 

TESTED  BY: _ 

REMARKS: 
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SYSTEM  DESIGN  DCXUMEMTATION 


TEST  PLAN 


REQUIREMENT:  1.3  -  Allow  user  to  inspect  selection. 

TEST  CASE(S)  : 

1.  Enter  selection  into  field. 

2.  For  multi-field  form,  allow  back-up  to  enter  or  change 
field  data. 

EXPECTED  RESPONSE: 

1.  Control  of  program  is  not  returned  until  terminator  is 
initiated  by  user. 

2.  Use  of  backspace  key  allows  user  to  return  to  previously 
defined  fields. 

RESULTS: 

CASE  1.  -  PASS; _  FAIL: _  DATE: _ 

CASE  2.  -  PASS: _  FAIL: _  DATE; _ 

TESTED  BY:  _ ^ 


REMARKS 


SYSTEM  DESIGN  DOCUMENTATION 
TEST  PLAN 

REQUIREMEMT:  1.4  -  Allow  user  to  specify  either  faculty  or  student 

database  use. 

TEST  CASE(S) : 

1.  Enter  allowed  digit. 

2.  Enter  more  than  one  digit. 

3.  Enter  other  than  digit. 

4.  Enter  other  than  allowed  digit. 

EXPECTED  RESPONSE: 

1.  Entry  accepted  and  waits  for  terminator. 

2.  Terminal  displays  ill-will  by  'beeping'  and  subsequent 
digits  not  accepted. 

3.  Terminal  'beeps'  and  displays  messsage  in  line  25 
signifying  user  to  enter  digit. 

4.  Message  displayed  that  entry  is  invalid  and  control  returned 
to  beginning  of  selection  process. 

RESULTS: 


CASE 

1.  -  PASS: 

FAIL: 

DATE: 

CASE 

2.  -  PASS; 

FAIL: 

DATE; 

CASE 

3.  -  PASS; 

FAIL: 

DATE; 

CASE 

4.  -  PASS: 

FAIL; 

DATE: 

1ESTED:_ 

REMARKS: 
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SYSTEM  DESIGN  DOCUMENTATICK 
TEST  PLAI'I 


REQUIREMENT:  1.5  -  Allow  user  to  specify  types  of  utility  to 

be  conducted. 

TEST  CASE(S)  : 

1.  Enter  allowed  digit. 

2.  Enter  more  than  one  digit. 

3.  Enter  other  than  digit. 

4.  Enter  other  than  allc^ved  digit. 

EXPECTED  RESPCNSE: 

1.  Entry  accepted  and  waits  for  terminator - 

2.  Alert  user  with  aural  signal  and  subsequent  digits 
not  accepted. 

3.  Alert  user  with  aural  signal  and  display  message  in  line  25 
signifying  user  to  enter  digit. 

4.  Message  displayed  that  entry  is  invalid  and  control  returned 
to  beginning  of  selection  process. 

RESULTS: 


CAEE 

1.  -  PASS: 

FAIL: 

DATE: 

CASE 

2.  -  PASS: 

FAIL: 

DATE: 

CASE 

3.  -  PASS: 

FAIL: 

DATE; 

CASE 

4.  -  PASS: 

FAIL: 

DATE: 

TESTED  BY: 
REMARKS: 
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SYSTEM  DESIQJ  DOOJMEOTATICN 


TEST  PLAN 


RECUIREMENT;  1.6  -  Allow  user  to  add/modify  data, 

TEST  CASE(S) : 

1.  If  entry  data  see  Test  Case  1.2  -  1.5. 

2.  Add  individual  data  to  database. 

3.  Modify  data  in  database. 

4.  Change  SSN  of  individual  after  calling  for  data. 

5.  Enter  data  not  intended  into  form  field. 

6.  Enter  more  than  expected  data  into  field. 

7.  Enter  less  than  specified  data. 

8.  Fail  to  fill  a  'Must-fill'  field. 

EXPECTED  RESPONSE: 

1.  Same  as  in  Test  Case  1.2  -  1.5. 

2.  Enter  data  into  form  fields. 

3.  Strike  over  data  already  contained  in  field;  abide  by 
field  characteristics  as  to  field  input. 

4.  Return  status  of  illegal  procedure  and  reject  operation. 

5.  Alert  user  with  aural  signal  and  message  to  line  25  on  screen. 

6.  Reject  data  of  more  than  specified  field  length  and  sound 
aural  signal. 

7.  Accept  data  unless  violation  of  No.  8. 

8.  Prior  to  form  terminator  accepted,  place  cursor  into 

'Must-fill'  field  and  sound  aural  signal. 

RESULTS: 


CASE  1.  -  PASS 

FAIL 

DATE: 

CASE  2.  -  PASS 

FAIL 

DATE: 

CASE  3.  -  PASS 

E'AIL 

DATE: 

CASE  4.  -  PASS 

FAIL 

DATE; 

CASE  5.  -  PASS 

FAIL 

DATE: 

CASE  6.  -  PASS 

FAIL 

DATE: 

CASE  7.  -  PASS 

FAIL 

DATE: 

CASE  8.  -  PASS 

FAIL 

DATE: 

TESTED  BY; 
REMARKS: 
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SYSTEM  DESIQI  DOCUMEIJIftTION 
lEST  PLAN 


reSXJIREMENT:  2.1  -;Create  or  initialize  data  files. 

TEST  CASE(S)  ; 

1.  Select  operation  for  individual  not  entered  into  database. 

2.  Select  operation  for  individial  entered  into  database. 

E3(PEJCTED  RESPONSE: 

1.  Individual  not  found;  displays  form  to  allow  user  to  input 
data  for  inclusion  into  database. 

2.  Individual  found;  displays  individual  form  data  contained 
within  database. 


RESULTS: 


SYSTEM  DESIGN  DOOMENTATICN 
TEST  PLftN 


rEQUIREMEKT;  2.2  -  Map  selected  utility  to  proper  application 

program . 


TEST  CASE(S) : 

1.  Select  one  of  offered  choices. 

2.  Select  choice  not  offered. 

3.  Enter  non-sensical  choice. 

4.  Enter  no  choice. 

EXPECTED  RESPCNSE: 

1.  Proper  utility  corresponding  with  selection  is  begun. 

2.  Sound  aural  signal  and  display  message  in  line  25  of  screen. 

3.  Sound  aural  signal  and  display  message  in  line  25  of  screen. 

4.  Sound  aural  signal  and  display  message  in  line  25  of  screen. 

RESULTS; 


CASE  1.  -  PASS; 

FAIL: 

DATE: 

CASE  2.  -  PASS; 

FAIL; 

DATE: 

CASE  3.  -  PASS; 

FAIL: 

DATE; 

CASE  4.  -  PASS: 

FAIL: 

DATE; 

TESTED  BY; 
REMARKS; 
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SYSTEM  DESIQJ  DOCUMEMTATICN 


TEST  PLAN 


REQUIREMENT:  2.3  -  Minimize  the  amount  of  variables/  linlcs, 

data  sets  looked  at  during  data  manipulation 


TEST  CASE(S)  : 

1.  Log  on  database  for  single-user  operation. 

2.  Log  on  database  for  multi-user  opera ticn. 

E2CPE!CTED  RESPCNSE: 

1.  Able  to  manipulate  database  with  single  user;  with 
multiple  users  able  to  manipulate  database  data-sets 
of  those  data-sets  not  held  by  another  laser. 

2.  Able  to  manipulate  like  (^rations  simultaneously. 

RESULTS: 

CASE  1.  -  PASS: _  FAIL: _  DATE: _ 

CASE  2.  -  PASS: _  FAIL: _  DATE: _ 

TESTED  BY: _ 


REMARKS: 


SYSTEM  DESIQl  DOCUMENTATIOSI 


TEST  PLAN 


REQUIREMENT:  2.4  -  Return  error  status  to  user. 

TEST  CASES (S) : 

1.  Call  TOTAL  and  display  eanror  code. 

2.  Display  error  code  for  those  codes  specified  in 
STDIRESULTS. 

3.  Display  error  code  for  error  not  listed  in  SIDTOESULTS. 

4.  Check  for  returned  error  after  each  type  DATBAS  call. 

EXPECTED  RESPONSE: 

1.  Four  character  error  code  displayed. 

2.  After  specific  module  utilizing  DATBAS  call,  error  code 
stored  in  STOIRESULTS ,  vtfiich  matches  returned  code,  is 
displayed. 

3.  After  specific  module  utilizing  DATBAS  call,  error  code 
not  stored  in  STDTRESULTS  is  displayed. 

4.  Error  status  or  '****'  returned  after  each  DATBAS  call. 

RESULTS: 


CASE  1:  -  PASS; 

FAIL: 

DATE;_ 

CASE  2.  -  PASS: 

FAIL: 

DATE:_ 

CASE  3.  -  PASS: 

FAIL: 

DATE: _ 

CASE  4.  -  PASS: 

FAIL: 

DATE: 

TESTED  BY: 


REMARKS; 


SYSTEM  DESIGN  DOCUMENTATICN 
TEST  PLAN 

REQUIREMENT;  3.1  -  Allow  user  to  gracefully  terminate  session 
TEST  CASE(S) ; 

1.  Terminate  an  active  database  interaction  session. 

2.  Attempt  to  terminate  sessiOTi  using  non-standard  means. 

EXPECTED  RESPONSE; 

1.  Session  terminated/  all  database  transactions  completed 
and  databcise  updated. 

2.  Session  terminated,  files  in  use  remain  locked  and  database 
net  closed. 

RESULTS; 

CASE  1.  -  PASS; _  FAIL; _  DATE; _ 

CASE  2.  -  PASS; _  FAIL; _  DATE; _ 

TESTED  BY;  _ 


REMARKS 


SYSTEM  DESIGN  DCX3JMENTATICN 


TEST  PLAN 

RECUIREMEIJT;  3.2  -  Deallocate  resources* 

TEST  CASE(S) : 

1.  Terminate  TOTAL  database  session  and  return  to  inactive 
status. 

EXPECTED  RESPONSE: 

1.  TOTAL  updates  database,  unlocks  used  data-sets,  and 
prc^rly  logs  off  the  user(s). 

RESULTS: 

CASE  1.  -  PASS: _  FAIL: _  DATE: _ 

TESTED  BY; 


REMARKS: 


SYSTEM  DESIGN  DOCUMENTATTCN 


TEST  PLftN 


REQUIREMENT:  3.3  -  Return  error  status  to  user  to  forestall 

unnecessary  delays  tn  database  usage. 

TEST  CASE(S)  : 

1.  Sign-on  to  databeise  with  database  specified. 

2.  Sign-cxi  to  database  without  databeise  specified. 

EXPECTED  RESPONSE: 

1.  Normal  operation  of  databeise  usage. 

2.  Normal  operation  of  a^Jlication  program  up  to  Sign-on 
and  no  database  operation. 

RESULTS: 

CASE  1.  -  PASS: _  FAIL: _  DATE: _ 

CASE  2.  -  PASS: _  FAIL: _  DATE: _ 

TESTED  BY: _ _ 


REMARKS 


SYSTEM  DESICSI  DOCUMEMTATICN 


TEST  PLAN 

REQCJIREMEMT:  3.4  -  Log  off  database  properly. 

TEST  CflSE(S)  : 

1.  Follow  menu  process. 

2.  Exit  using  non-standard  procedures. 

EXPECTED  RESPCNSE: 

1.  Normal  Sign-off  procedure. 

2.  Returns  use  of  terminal  to  user,  but  fails  to  update 
database,  unlock  user  data-sets,  or  Sign-off  frcm  TOTAL. 

RESULTS: 

CASE  1.  -  PASS; _  FAIL: _  DATE: _ 

CASE  2.  -  PASS; _  FAIL: _  DATE: _ 

TESTED  BY;^ - - - - - 


REMARKS: 


SYSTEM  DESIQI  DOCUMEMTATICN 


TEST  PLAN 


REfiOIREMEMT;  4.1  -  Create  output  forms. 


TEST  CASE(S)  : 

1.  No  report  requested. 

2.  A  report:  requested. 

ESCPECTED  RESPCNSE: 

1.  No  report  generated. 

2.  A  report  generated. 

RESULTS: 

CASE  1.  -  PASS: _  FAIL: 

CASE  2.  -  PASS: _  FAIL: 

TESTED  BY: 


DATE: 

DATE: 


REMARKS 


SYSTEM  DESIGN  DOCUMENTATION 


TEST  PLAN 


REQUIREMENT:  4.2  -  Print  output  forms  by  user  selected  device. 
TEST  CASE(S) : 

1.  No  device  selected. 

2.  Printer  device  selected. 

3.  Terminal  selected. 

EXPECTED  RESPONSE: 

1.  Output  displayed  to  terminal. 

2.  One  copy  printed  to  selected  printer  device. 

3.  Output  displayed  to  terminal. 

RESULTS: 

CASE  1.  -  PASS: _  FAIL: _  DATE: _ 

CASE  2.  -  PASS: _  FAIL: _  DATE: _ 

CASE  3.  -  PASS: _  FAIL: _  DATE: _ 

TESTED  BY: _ 


REMARKS 


SYSTEM  DESIGN  DCCUMENTATia^ 


TEST  PLAN 


REQUIREMENT:  4.3  -  Display  output  data  on  terminal. 

TEST  CASE(S) : 

1.  No  terminal  display  requested. 

2.  Terminal  display  requested. 

EXPECTED  RESPONSE: 

1.  No  terminal  display  presented. 

2.  Output  froti  databcise  utility  displayed  to  terminal 
RESULTS: 

CASE  1.  -  PASS: _  FAIL: _  DATE: _ 

CASE  2.  -  PASS; _  FAIL: _  DATE: _ 

TESTED  BY; 


REMARKS 


The  follcwing  begins  the  System  Design  documentation  consisting  of 
Data  Flow  Diagrams  and  Structure  Chart  information.  Each  graphic  sec¬ 
tion  contains  a  diagram  index  and  the  graphic  representations.  The 
documents  specify  the  order  of  the  anticipated  database  drive  package 
including  e3<pansicxi  capability. 


structure  Charts  —  User  Interface 


Choosenenu 


Structure  Charts  —  User  Interface 


ChooseaE^rog  ;; 


Structure  Charts  —  User  Interface 


structure  Charts  —  User  Interface 


Driver 


This  portion  ccxitains  the  Structure  Diagrams  for  the  user  inter¬ 
face  of  the  expanded  AFIT/ENG  database.  As  with  the  Data  Flew  Dia¬ 
grams  (above) ,  the  documents  specify  the  order  of  the  anticipated 
database  driver  pacdcage  including  its  expansion  c^)ability. 


Close  Database 


Service  Request 


Figure  M-2.  AFIT  Database  Utilizaticxi  (Level  1.0) 


Fiquro  M-1.  AFIT  Database  Utilization  (Level  0) 


Figxire  0  -  AFIT  Database  Utilization 

Process  0  -  Manipulate  AFIT  Database 

Figure  1  -  AFIT  Database  Utilization 

Process  1  -  .Open  Database 
Process  2  -  Determine  Request 
Process  3  -  Service  Request 
Process  4  -  Provide  Output  to  User 
Process  5  -  Close  Database 

Figure  1.1  -  Open  Database 

Process  1.1  -  Evaluate  Request 
Process  1.2  -  Allocate  Resources 
Process  1.3  -  Load  DBMS 

Figure  2.1  -  Determine  Request 

Process  2.1  -  Check  Database  Status 
Process  2.2  -  Shew  Main  Menu 
Process  2.3  -  Show  Error  Code 

Figure  3.1  -  Service  Request 

Process  3.1  -  Display  Next  Menu  List 
Process  3.2  -  Display  Special  Menu  List 
Process  3.3  -  Display  Form  Choice 
Process  3.4  -  Act  on  Display  Form 
Process  3.5  -  Update  Database 

Figure  4.1  -  Provide  Output  to  User 

Process  4.1  -  Determine  Output  Media 
Process  4.2  -  Select  Printer  Type 

Figure  5.1  -  Close  Database 

Process  5.1  -  Evaluate  Request 
Process  5.2  -  Deallocate  Resources 
Process  5.3  -  Close  Database  Files 


structure  Charts  —  User  Interface 


structure  Charts  —  User  Interface 


:ure  Qiarts  —  User  Interface 


Appendix  N 

Proposed  AFIT  Database  Administration 


Many  points  of  view  have  been  asked  for  prior  to  and  during  the 
design  of  the  database.  Each  interview  produced  a  list  of  desires  and 
expectations  concerning  the  proposed  databa.se  result  (Appendices  B 
and  D) .  With  this  in  mind  it  is  not  surprising  that  a  requirement 
exists  for  someone  to  be  respcxisible  for  not  only  vdiat  is  ccxitained 
within  the  databeise  but  also  how  data  is  safegucurded,  changed  and 
accessed.  This  requirement  is  filled  by  the  Data  Bcise  Administrator 
(DBA) . 

Responsibility 

The  role  of  the  DBA  is  most  important  not  only  to  the  database  but 
also  the  organization.  Changes  to  the  database  are  expected.  However, 
future  changes  can  be  done  more  rapidly,  ccrcpletely,  and  easily  based  . 
oi  the  documentation  produced  vdiile  building  the  database.  The  DBA 
should  exert  control  to  insure  that  any  databeise  changes  cone  complete 
with  proper  documentation,  and  that  all  users  and  programmers  adhere  to 
accepted  policies.  These  acts  enhance  the  usefulness  of  changes  affect¬ 
ing  any  part  of  the  database  and  its  subsequent  use  to  the  organiza¬ 
tion. 

There  is  no  universal  definition  of  a  DBA;  it  is  unique  to  the 
enterprise  (28:120) .  Ideally,  the  Database  Administrator  is  the  func¬ 
tion  within  the  enterprise  that  is  created,  organized,  and  staffed  to 
manage  the  data  resource.  Having  respcnsibility  for  the  resource,  the 
DBA  must  be  granted  the  authority  to  control  and  manage  the  Dateibase. 


Inasmuch  as  there  is  effectively  one  organization  involved  in  the  ccai- 
trol  and  use  of  the  AFIT  database,  no  discussion  is  offered  as  to  the 
need  to  integrate  the  DBA  with  the  other  data  generating  or  data  using 
parts  within  the  organization.  This  DBA  autcroatically  receives  suffi¬ 
cient  support  from  the  Department  Head  within  the  Department  of 
Electrical  Engineering. 

The  DBA  scope  of  responsibility  is  clearly  not  limited  to  the 
functional  areeis  regeurding  data  residing  in  a  ccttinon  file  or  those  man¬ 
aged  by  a  single  DBMS.  The  integrated  data  are  not  the  total  resource 
and  in  many  cases  they  are  the  smallest  portion  of  the  data.  A  defini¬ 
tion  of  responsibility  limited  to  integrated  data  is  a  cleeir  invita¬ 
tion  for  user-generated  and  user-maintained  files.  The  DBA  must  assume 
responsibility  for,  and  control  of  all  machine  processable  data,  includ¬ 
ing  the  input  and  output  files  used  to  update  the  database  and  the  re¬ 
port  files  generated  from  it.  It  must  include  those  tenporary  files 
used  by  a  one-time  application,  for  the  files  that  are  created  and  main- 
tciined  under  a  time-sharing  system,  and  it  must  extend  to  include  those 
files  naintained  by  a  service  bureau  or  a  facilities  manager  (28:122) . 

Functionality 

To  fulfill  its  responsibility  to  the  enterprise  as  a  resource  man¬ 
ager,  the  DBA  must  lead  the  design  of  the  database  and  any  subsequent 
additiais.  The  DBA  must  assume  primary  responsibility  for  all  activi¬ 
ties  that  are  capable  of  altering  the  contents  of  the  database  and  for 
those  related  activities  that  represent  a  significant  investment  in  com¬ 
puter  resources.  The  functions  to  be  performed  by  the  DBA  may  be  di¬ 
vided  into  three  areas",  definition,  existance,  and  utilization  (28:124). 


N-2 


The  definiticsi  aspects  of  the  database  are  related  to  design, 
its  reduction  to  a  definition  in  the  schema,  the  user's  definition  of 
the  subschata,  the  data  dicticaieiry,  and  the  narrative  descriptions 
that  are  the  basis  of  cormunication.  Although  these  definition  func¬ 
tions  rely  an.  the  users,  they  cure  the  sole  responsibility  of  the  DBA. 

The  physical  functions  aissociated  with  the  existance  of  the  data¬ 
base  include  initial  load,  accommodation  of  growth,  quality  cissurance, 
protection,  and  restcurt:  and  recovery.  All  irust  be  assigned  to  the  DBA 
in  order  to  properly  manage  the  resource  effectively.  This  ccities  under 
the  realm  of  security  to  sone  degree  eis  well.  One  of  the  pressing  con¬ 
cerns  of  a  user  is  the  assurance  th?t  'his*  data  cannot  be  inadver¬ 
tently  damaged  or  accessed  by  someone  else.  This  concern,  bred  in  the 
era  of  tape,  is  based  on  the  fact  that  if  a  program  can  access  one  of 
the  records  in  an  area  of  the  database  it  can  autcmatically  access  all 
of  than.  In  the  case  vrfbere  the  DBMS  discourages  the  use  of  multi 
record- types,  the  prograitmer  must  decide  procedural ly  through  coding 
v»hich  type  of  record  he  has  accessed.  To  assure  the  user  that  an  error 
in  determining  record  type  does  not  occur,  it  may  be  necessary  to 
segregate  records  by  type  (28:76) .  This  type  of  schana  is  the  one  we 
cire  familiar  with  in  the  TOTAL  DBMS.  Also,  the  ability  to  code  vari¬ 
able  data-sets  within  TOTAL  can  lend  inplicit  secvirity  to  the  coding 
itself  (19:4-17) .  Recovery  can  be  concerned  with  validity,  getting 
back  to  the  correct  state  of  the  database,  error  correction  routines, 
routines  for  taking  snapshots  or  copies  of  the  database  (backups) ,  and 
audit  tradl  routines,  to  name  but  a  few. 


The  third  function  assigned  to  the  DBA  ccncems  utilization  of  the 
database  and  efficiency  considerations  that  effect  database  avail¬ 
ability  vrtiile  it  is  operational.  Such  concerns  include  detection  of 
procedures  that  cause  resource  contentiOTi  through  concurrent  access 
protection  achieved  at  the  expense  of  availability  regardless  of  the 
level  at  vdiich  access  is  ccaitrolled. 

The  tasks  of  restructuring  and  evaluating  load  density,  program 
efficiency,  and  access  patterns  are  normally  accepted  to  be  DBA  fmc- 
tions.  If  the  DBA  is  a  resource  manager,  it  must  be  possible  to  mea¬ 
sure  the  database's  performance.  This  is  a  task  which  has  had  two 
specific  AFIT  theses  (23  and  25)  conpleted  already,  and  their  results 
should  be  incorporated  within  the  tcisks  required  of  the  DBA.  Proper 
applicatiCTi  of  these  types  of  performance  tools  help  to  lend  cred¬ 
ibility  to  the  DBA,  for  its  job  performance  can  aptly  be  measured  in 
terms  of  the  tiirely,  accurate,  consistent  and  complete  data  conducted 
during  the  normal  usage  of  the  database. 

Also  embedded  in  this  operation  can  be  the  techniques  employed  by 
the  users  (or  program  authors) .  There  is  more  than  one  way  to  write  a 
program;  consequently,  there  is  the  c^portunity  to  do  it  either  better 
or  worse.  Increasing  the  odds  in  favor  of  'better'  can  also  be  a  task 
the  DBA  would  want  to  monitor.  However,  care  must  also  be  taken  to  in¬ 
sure  that  the  efficiency  imprx3vements  yield  absolute  improvements  that 
are  large  enough  to  justify  the  effort  required  to  attain  them  (28:126) . 
To  fulfill  its  respcxisibility  for  database  accessability,  the  DBA  must 
develop  an  active  twofold  program  to  improve  the  quality  of  applications 
that  access  the  datcibeise  to  insure  that  designers  and  programmers  are 
aweure  of  the  techniques. 


The  concerns  of  security  continue  to  be  an  increeisingly  inportant 


natter.  This  will  become  more  acute  cis  the  users  expand  to  include 
most  faculty  and  students  within  the  Department.  Since  TOTAL  can  be 
ccxifigured  to  be  multi-user  (19:4-53),  and  the  intent  is  for  the  data¬ 
base  to  serve  the  needs  of  the  Department  of  Electrical  Engineering, 
the  requiranent  to  allow  students  access  to  the  database  to  look  at 
and  change  their  Ed  Plans  and  course  selections  begs  for  a  more  com¬ 
prehensive  means  to  control  access  to  particular  data-sets,  data-set 
items,  and  the  use  of  pctrticular  databcise  utilities. 

Staffing 

A  DBA  is  not  created  to  enlarge  the  data  processing  staff  (if  one 
exists)  but  to  manage  an  existing  resource  -  data.  When  the  database 
talents  are  dispersed  within  the  user  groups,  application  specialists 
are  distracted  from  their  primary  responsibility  to  cope  with  data¬ 
base  problems. 

The  person  selected  to  direct  the  activities  of  the  DBA  must  pro¬ 
vide  the  motivation  for  his  steiff  and  the  functional  users  to  use  the 
resource  effectively.  He  need  not  be  an  individual  personally  capable 
of  filling  each  st^f  positicxi.  He  should  be  technically  qualified,  be 
able  to  understand  the  subtleties  of  the  database  and  be  capable  of 
managing  technical  specialists. 

The  staff  must  have  at  least  one  expert  in  the  details  of  the  DBMS 
software.  In  case  of  failure,  this  individual  will  play  a  most  brport- 
ant  role  in  reestablishing  a  properly  functioning  database.  The  DBMS 
specialist  is  required  for  the  less  dramatic  aspects  of  the  DBA  to  in¬ 
sure  effective  utilization  of  the  DBMS  for  initial  load,  recovery,  re¬ 
structuring,  cuid  so  forth  (28:129). 
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The  DBA  staff  must  include  persons  with  application  progranming  and 
systems  design  experience.  They  must  have  experience  with  the  use  of  the 
c^ierating  systan,  the  hardware,  and  the  utilities  (like  EHS)  in  order  to 
perform  their  special  functions. 

Maintenance  of  the  data  dictionary  does  not  require  the  same  type  of 
technician  as  the  maintenance  of  software.  Though  not  clerical,  this  job 
does  require  a  different  personality  and  teirperament  than  is  required  of 
the  software  expert.  The  data  dictionary  can  be  maintained  best  by  a 
person  with  an  ^plications  background  who  can  appreciate  the  meaning  of 
data  and  how  they  are  used  (28:130) . 

The  quality  eissurance  and  audit  functions  require  the  stability  of 
the  applications  specialist  and  the  inquisitiveness  of  the  technician. 

The  way  a  database  is  used  suggests  those  areas  in  which  errors  are  likely 
to  occur  and  vdiere  inccxisistencies  can  be  expected. 

The  AFIT/ENG  DBA 

Ideally,  the  DBA  should  consist  of  a  director,  a  software  maintenance 
expert,  a  person  with  a  strong  application  background  to  interface  with 
the  users,  a  databeise  techniques  specialist,  and  the  person  who  maintains 
the  data  dictionary,  schema,  and  subschema  and  handles  restarts.  These 
are  the  priitary  functions.  If  possible,  the  DBA  should  contain  positions 
that  can  be  filled  by  user  and  data  processing  personnel.  Of  the  many  ways 
to  iirprove  the  quality  of  the  data  processing  and  user  staffs,  one  of  the 
most  effective  is  the  active  rotation  of  personnel  among  the  different 
functional  areas,  including  the  DBA  (28:126).  This  may  or  may  not  serve 
the  same  purpose  within  such  a  small  organization  like  AFIT/ENG. 
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Taking  into  account  the  size  and  fianctions  of  the  AFIT/ENG  data¬ 
base,  the  DBA  could  prc?5erly  be  conposed  of  one  administrator,  one 
software  maintenance  expert  who  also  interfaces  with  the  users  and 
acts  cis  the  database  techniques  specialist,  and  one  person  v\^o  main¬ 
tains  the  data  dicticaiciry,  schema,  and  related  resources.  Additional 
theses  concerning  the  AFIT/ENG  database  could  draift  the  student 
undertaking  the  task  and  place  him  within  the  DBA  as  a  DBMS  or  applica¬ 
tions  programs  specialist. 

The  person  selected  to  direct  the  activities  of  the  DBA,  called 
the  Data  Base  Management  Administrator  (DBMA) ,  will  control  all  as¬ 
pects  of  the  utilization  of  the  database,  be  responsible  for  any 
scheduled  input  or  output  matter  and  their  format,  designate  the  data¬ 
base  schema  design,  and  direct  the  inclusion/deletion  of  database 
application  programs  and  subsequent  record  structures  and  database 
usage. 

The  busiest  of  the  three,  on  a  daily  basis,  regetrding  the  data¬ 
base,  will  probably  be  the  multi-faceted,  software  maintenance  expert, 
the  Data  Base  Technical  Advisor  (DBTA) .  His  tasks  will  range  frcm  the 
actual  database  construction,  security  of  the  database,  upkeep  and 
expansion,  write  or  oversee  tlie  writing  and  inclusion  of  application 
programs  within  the  databcise,  and  act  as  the  resident  database  expert 
for  daily  operations. 

The  Data  Base  Clerk  (DBG)  will  maintain  the  data  dictionary, 
schema,  and  current  listings  and  modifications  of  the  database  and 
application  programs.  The  Clerk  will  also  maintain  the  configuration 
control  and  act  under  the  direction  of  the  DBTA  and  DBMA. 
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The  Form  Management  System 

An  available  utility  on  the  existing  hardware  is  the  softv/are  pack¬ 
age  from  Digital  Equipment  Corporation  (DEC) ,  the  Form  Management  Sys¬ 
tem  (EMS) .  It  is  designed  for  ease  of  formulation  and  form  sirolation 
in  order  to  collect  and  transmit  data  in  an  orderly  manner.  Forms  are 
designed  by  typing  them  directly  onto  the  terminal  screen.  Neither  lay¬ 
out  charts  nor  a  special  forms  design  language  is  required.  EMS 
associates  constant  data  with  the  form,  not  with  the  application  pro¬ 
gram,  resulting  in  siitplified  application  program  maintenance  and  in¬ 
creased  application  program  flexibility.  Forms  may  later  be  modified 
without  the  need  to  recompile  the  application  program  (as  long  as  the 
form  does  not  change  application  program  specific  areas) .  This  utility 
supports  any  language  supported  by  the  VAXA'MS  host  ccmputer  (20:1-1) . 

The  order  of  the  data  contained  on  the  EMS  screens  is  determined 
by  grouping  data  items  by  category,  and,  to  a  lesser  extent,  by  screen 
requirements.  Each  screen  was  created  to  present  cohesive  areas  for 
data  input  and  to  make  judicious  use  of  limited  space.  Screen  require¬ 
ments  pertain  to  the  data  collection  precedence  within  the  EMS  (top-to- 
bottcm  and  left-to-right) .  In  an  effort  to  show  all  personal  data  on 
the  CRT  screen  at  once  without  having  to  scroll  through  an  area  to  see 
it  all,  the  selecticxi  option  was  to  forego  the  use  of  scroll  areas.  All 
personal  data  was  still  grouped  by  category.  For  an  exaitple,  see  Figure 
1-5.  The  most  often  accessed  student  data  precedes  the  data  less  often 
changed  to  acconmodate  the  anticipated  changes  required  to  be  performed 


by  the  user  (secretary,  student,  etc).  Thus,  a  student's  rank  (item 
5)  and  service  (item  7),  precede  the  student's  place  of  birth  (item  22) 
and  his  previous  ccnmand  (item  28) ,  which  will  not  conceivably  change 
while  at  AFIT. 

The  Form  Editor 

The  Form  Editor  (FED)  simplifies  designing,  modifying,  and  stor¬ 
ing  form  descriptions  for  video  display.  The  screen  always  shows  the 
current  state  of  the  form  v\hile  it  is  being  edited.  Keypad  and  key¬ 
board  functions  provide  ways  to  specify  video  display  characteristics 
for  constant  text  or  fields  that  ccaitain  picture  characters.  To  help 
operators,  short,  helpful  explanations  about  individual  fields  may  be 
included  as  well  as  separate  help  forms  as  required  (20:1-2) . 

When  designing  forms,  the  prograimer  assigns  form  names  and  field 
names  to  reference  data  used  (but  not  displayed)  by  the  Form  Driver 
when  the  form  is  used  by  (or  within)  an  application  program.  Also,  the 
desired  operator  response  to  information  displayed  or  data  to  be  entered 
on  forms  is  controlled  by  the  actual  design  of  the  form  and  the  specific 
application  requirements  (20:1-2).  An  exanple  is  in  EMS  form  STDT.FRM. 
When  providing  "MIL/CIV  RANK"  data,  the  form  only  accepts  three  char¬ 
acters  within  the  field.  The  first  character  must  be  an  alphabet 
character  and  the  other  two  characters  must  be  digits  0-9.  Failure  to 
provide  the  expected  response  for  each  character,  rings  the  terminal 
bell  and  rejects  the  input.  This  is  not  to  be  confused  with  conplete 
entry  error  checking.  An  expected  response  to  this  field  is  '04' 

(for  MAJ  rank)  or  'G12'  (for  civilian  grade) .  An  accepted  response 


could  be  'w89' 


Creating  or  editing  a  form  with  the  Form  Editor  is  interactive 
and  iterative.  After  creating  a  form,  it  can  then  be  ccmbined  with 


others  to  form  a  library  from  which  they  can  be  retrieved  and  used  by 
specific  application  programs.  The  most  useful  part  of  this  utility 
is  the  ability  to  change  a  form  format  or  look  (such  as  using  reverse 
video  attributes  for  any  pairt  or  all  of  the  form)  after  the  form  is 
already  part  of  an  application  program  and  have  little  or  no  inpact 
upon  the  related  application  program  (20:2-1) . 

Unfortunately,  nothing  is  for  free.  The  direct  linking  of  the 
utility  with  an  application  program  was  not  described  or  explained  in 
the  reference  (17) .  Also,  all  applications  were  expected  to  be  written 
in  Pascal.  However,  no  documentation  for  the  interconnection  or 
relating  of  this  utility  using  the  Pascal  language  was  available.  This 
caused  time  spent  to  determine  hew  to  relate  the  utility  with  Pascal, 
after  first  determining  how  to  write  and  enable  a  working  driver  in 
Fortran.  This  drawback  was  accomplished  at  the  expense  of  time  which 
could  have  been  utilized  creating  requested  application  programs. 

The  Form  Utility 

The  Form  Utility  (FUT)  allows  the  prograitmer  to  create  versions 
of  form  descriptions  that  are  suitable  for  hard-cepy  listings,  to 
create  and  modify  form  libraries,  and  to  list  the  names  of  forms  con¬ 
tained  in  a  form  library.  This  also  includes  extracting  and  deleting 
form  descriptions  from  form  libraries,  and  combining  form  descriptions 
and  form  libraries  into  large  form  libraries  (20:1-2). 


The  Fom  Driver 

The  Form  Driver  (FDV)  is  the  heart  of  the  usefulness  of  the 
utility.  It  is  a  set  of  subroutines  that  permit  the  application  pro¬ 
gram  to  access  forms  created  using  the  Form  Editor.  In  an  af^lication 
that  uses  video  images  of  forms  an  the  terminal  screen,  using  the  Form 
Driver  can  reduce  the  programming  effort  by  manipulating  the  screen, 
checking  responses  that  an  operator  types,  and  displaying  help 
messages  and  forms  v^ien  the  operator  requests  them  (20:1-2) . 

Application  programs  access  forms  by  issuing  Form  Driver  calls 
that  cire  embedded  in  the  program  and  are  written  in  the  source  lan¬ 
guage  of  the  program.  All  Form  Driver  calls  refer  to  specific  forms  and/ 
or  fields  within  forms  by  names  assigned  during  the  form  editing 
process . 

The  Form  Driver  performs  field  and  character  validation  for  opera¬ 
tor  input  based  on  the  form  definition  (validation  is  based  on  picture 
validation  characters  and  field  attributes) .  The  Form  Driver  also 
responds  to  operator  'Help'  requests  by  displaying  help  text  associated 
with  the  form  and  field  being  processed  (20:4-2) . 

The  Form  Driver  is  by  feu:  the  most  ccnplicated  and  time  consum¬ 
ing  of  the  major  portions  of  this  utility  to  initialize  and  get  work¬ 
ing.  The  provided  manual  is  very  helpful  but  it  does  not  provide 
reference  for  actually  using  the  utility  in  an  application.  The 
reference  does  provide  explanations  and  a  few  written  programs  to  use 
as  guides.  However,  the  sample  program  source  code  provided  had 
numerous  errors  which  prohibited  it  from  compiling  and  running. 
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study  undertcuk  a  CGu;plete  rivisict:  and  reassign  of 
t.-.e  database  in  an  effort  to  expand  existing  cap- 

tbili-ios  and  utilities.  T'he  dcft-.vare  7  e  velo  cnen  t  life  "'yole 
approac'n  was  utilized  tnroujhout  this  croject  in  order  to 
provide  a  basis  for  sound  software  enpinoerinT  crinoioles 
and  provide  for  a  sound  database  develonr.ent  base,  '’he 
initial  compilation  of  data  was  obtained  by  interviewing  a 
wide  range  of  individuals  to  determine  essential  needed 
functions  as  well  as  recuested  data  reouire.r.encs.  The  results 
were  combined  to  form  the  specific  network  master  and  variable 
data-sets  for  use  with  anticipated  application  progra.ts  for  a 
greater  database  utility. 

The  expanded  database  exhibits  the  means  to  manipulate 
student  and  faculty  data  as  well  as  provide  for  the  inclusion 
of  advanced  data  handling  routines  like  education  Plan  and 
'Graduate  ’’redit  '^ecord  utilities,  ''’o  insure  standard  data 
input  and  output  as  well  as  provide  a  mere  user  friendly 
environment ,  a  menu  form  display  technique  was  incorporated 
witnir.  the  expanded  database  driver.  .  The  resultant  program 
.was  designed  for  modularity  and  expansion  v/ith  little  additional 
coding  recuired  to  connect  future  da/cabase  arolication  routines. 
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